個人開発でのFirestore利用を念頭においた、NoSQL 基礎の基礎の基礎の整理
※時系列順に書いてます。あしからず。
事の発端
Firestoreの設計がわからない。というかNoSQLも入門していない。よってドキュメント指向DBの設計などわかるはずもなく。 大雑把にでも強み・弱みくらいは把握できればそもそもRDBを選択するべきか否かが見えてきそうなので調べる。
NoSQLを採用すると幸せになれそうなとき
「そもそもNoSQLとは」みたいなことをAWSの公式から引用させてもらうと、非リレーショナルDBくらいの意味で捉えれば良さそう。
で、NoSQLはどんな幸せをもたらしてくれるかという話だが、大きく4つあるっぽい。
- スケーラビリティ
- 高性能
- 高機能
- 柔軟性
これらを求めるときにはNoSQLはいいということだがざっくりしすぎていて分かりづらい。ただ堅牢性が入っていないので、堅牢性（トランザクションがどうとかそういうこと）はRDBに軍配があがりそう。例えば下記サイトにもそのような記載がある。
高性能・高機能は、下記で述べるNoSQLの中でもさらに5つに分岐した中から適切なものを選ぶことでよりよりパフォーマンスを発揮してくれるそう。
スケーラビリティに関しては、個人開発アプリだからそこまで必要ないかな…？ただし痰壺さんの事例があるので一応頭の片隅に入れておいてもいいかも。
僕の好みに合いそうなのは柔軟性。具体的にはデータモデルの柔軟性がメインみたい。データモデルは下記から選べる。それがそのまま○○型DBと呼ばれるようす。
- キーバリュー型
- ドキュメント型
- 検索型
- インメモリ型
- グラフ型
Firestoreが属する「Document型」
AWS公式にはドキュメント型DBを用いる理由として
「開発者にとって、データモデルをドキュメントとして考える方が直感的である」
と書かれている。この直感的というのは好みではあるが、正直現段階では実感がわかない。恐らくこれは実際に設計・開発してみないと分からなさそう。
と思っていると「直感的」の具体度を上げた例として
「アプリケーションコードで使用するのと同じドキュメントモデル形式を使用してデータをデータベースに保持できる」
とある。これは開発する前からある程度想像がつく利点だ。
規模感と事例
じゃあどれくらいの規模のアプリならばいいのだろう。「便利だけど、アプリがデカいから読み書きがとてつもなく遅くなってしまいました〜」では用いることはできない。まぁ個人開発でそこまでアプリが大きくなることなど本当に稀だと思うけど…。ということで存在している事例で問題なく動いているものがあれば一旦の安心材料（※安全とまでは言い切れない意味。気休めくらい。）にはなるかなということでググってみる。
とかいってたらFirestore設計の参考情報まとめ記事があった。
これ。
特にmonoさんの記事は分かりやすい…。FlutterといいFirebaseといい（Swiftは全くわからないので…すみません。）とても分かりやすい記事が多いのでmonoさんの記事は気づいたら見てますね。 詳細はここを読もう。（笑）
あと参考になったのはここ。ググったらすぐ出てくる。
データをリレーショナル形式に整形しなくて済むのでOR Mapperの選定と実装の手間が省ける。キーバリュー型よりドキュメントのほうが複雑なことができるらしい。ただし残念な点としては結合が多いのは向いてないとのこと。
