RDB 脳の私が NoSQL に挑戦して苦しんだ末に導き出した設計書のベストプラクティス

こんにちは！株式会社キカガクの開発事業部でソフトウェアエンジニアをしている塚井です。RDB 脳の私が NoSQL に挑戦して苦しんだ設計書についての話を書こうと思います！

対象読者

NoSQL の設計書をどうまとめるか悩んでいる方向けの記事となります。

概要

現在のチームでは NoSQLデータベースである Cloud Firestore を利用しています。この Firestore の構造をまとめるのに yaml ファイルを採用しました。その経緯と yaml のサンプルをご紹介します！

※ 本記事では Firestore の Document と混同しないよう以下の使い分けをします。

設計書：仕様などをまとめる資料
Document：Firestore の Document

試したもの

まず、背景として私は RDB に長年慣れ親しんできました。その際は A5SQL 一択だったのですが、Firestore に挑戦することになり設計書をどうまとめるか以下のように試していきました。

mermaid erDiagram

https://mermaid-js.github.io/mermaid/#/./entityRelationshipDiagram

DB といえば ER 図！という安易な考えと、導入のお手軽さで試しました。

結果、リレーションがないから意味がないのと、サブコレクションなどを表現するのがどうしても難しくあきらめました。

diagrams.net（旧 draw.io）

https://app.diagrams.net/

mermaid の自由度が低かったので、お絵かきツールでいいのではないかと試してみました。

結果、見やすくはなったのですがメンテナンスが大変なのと、たくさんコレクションがあるシステムだと逆に見づらくなりそうです。またお手軽さを重視して、.png で管理しようとしたら GitHub で変更差分がぱっとみ分かりづらいのが致命的でした。

yaml

Firestore は Collection と Document の種類と階層構造が分かればいいのではという結論に至り、ファイルの書き方のルールの一つである yaml を利用してみたところ以下のようなメリットだらけでした。

めちゃくちゃシンプルでメンテナンスも変更管理も超簡単！
コメントも入れ放題
必須項目かは使用言語が TypeScript なので ? で表現すれば開発メンバに分かりやすかった
firestore.rules とも構成が似ている

【サンプル】

# Firestore の設計
users:
  {userId}:
    # collection
    todos:
            {todoId}
            # collection
            # field
                title: string
                duedate?: timestamp # 期限は設定しなくてもよい
    # field
    name: string

結論

Firestore の公式 GUI では構造を簡単に把握することができないので、たくさんの Document を開いて中身を把握していましたが、yaml を使うことで Firestore の構造をあらかた表現できました。もしおすすめの設計書がありましたらぜひ教えてください！

キカガクは今急激に拡大中で開発メンバも増えており、新メンバにもこれで説明できるようになりましたので皆様のご応募お待ちしております！！

キカガクプラットフォームブログ

株式会社キカガクのプラットフォームブログです。エンジニアやデザイナー、プロダクトマネージャーなどが記事を書いています。