【Firebase】Firestoreについて自分なりにまとめてみる（随時更新）
迷いも含めて記述していきます。
設計
種類
冗長型と参照型がある。
設計時に迷うことは、ユーザーに紐づく情報を別のトップレベルのコレクションとして生成して参照させるか、それとも、あくまでユーザーに紐づく情報だからユーザー内に収めるか。問題となるのはユーザーに紐づくけども、それ単体でも集計を行いたい情報Aがあるとき。これはコレクションを新たに一つ設けてユーザー参照をもたせるほうが良いかと思う。
情報の切り方によって変える、と表現すればいいだろうか。例えば高校を舞台として生徒（以下studend）の科目の成績（score）をつけるアプリを開発したいとする。このときに「生徒別の成績」を確認したいだけなら、studentにscoreを紐付ければいいと思う。しかし、score別（例えば国語、数学、英語、世界史、日本史…といった具合）に誰がどの位置にいるのかなどを算出したい場合は、別途scoreをトップレベルのDocumentに持ってきたほうが都合が良さそう。パフォーマンスの実測などはしていないが考えやすいと感じる。
あとはマスタデータとトランザクションデータという観点で考えてみても面白そうだけどまだ明確になっていない。
Documentの名前を乱数にするかどうかは、トランザクションデータなんかは乱数で良いと思っていて、あとは予め名称が一意になることが決められていれば乱数にしなくてもいいと思う。例えば人名やハンドルネームは被る可能性があるので乱数でDocumentを作成する。しかし先程の例えで言うところの科目名は被らないので名前をそのままDocumentに適用しても問題なさそう。ただし、システム全体で統一性をもたせたいのならばDocumentはすべて乱数の自動採番にしてサブコレクションにname: hogeみたいなことをすればいいと思う。
Authentication UIDとFirestoreのDocument IDを一致させる方法
別途記事を書きます。
お金の話
なにをどうしたら、どのタイミングでお金がかかってくるのか。
基本的には読み取り回数に対してお金がかかる。日に5万回読み取りがあればお金がかかる。企業のtoCプロダクションが2.5万/日なら個人開発アプリなら大丈夫でしょう。。
苦手なこと
集計
GROUP BYなどが使えない。となるとやるとしたらクライアント側での処理、もしくはCloud Functionを介して集計・計算となる。
