この本がよい。
設計メモ(雑)
・複雑なクエリによってデータ加工することではなく、よく設計されたデータモデルと単純なクエリで解決するべき。
-> そのためにアグレッシブにスキーマ変更に取り組むことになる。 -> 将来の変更を予測して、データの欠損を起こさずにスキーマを変更できるような拡張性の高いデータモデルを考える. アグレッシブに schema を変えるための具体的な方法については当書籍の中では言及されていない。
一つの例としては、パスにバージョンを入れておくと endpoint を変えるだけでいけるのでよいのかも。
/version/1/user/:idこの場合は reference ではなく id を持っておかないと古い情報を参照してしまう。
{
"userID": "user_ID" // :id
"userReference": "<Ref>", // /version/1/user/:id
}Reference はいつ使うのか？ 新しいモデルから古いモデルを参照する時 ネストの深いモデルを参照する時
・原則として読み取りオペレーションで Cloud Functions を使ってはいけない。
・ドキュメントサイズが 1MB 以下
・リレーショナルデータベースように、「一回のクエリで複数レコードの特定の列をまとめて更新する」機能はない。（たぶん）
・security rule でスキーマの検証を行える。
・Firestore から取得されたデータはなるべくクライアントでの加工をせずにそのまま利用できることが期待される。
ドキュメント設計の指針としてはビュー（画面）やその構成要素であるコンポーネントを 1 回描画するために必要なデータを（『ドキュメントが業務上関連のあるデータの集合である』という前提を崩さない範囲で）１つのドキュメントにできるだけ詰め込むように設計する。 データの重複をある程度許容しフロントエンドに寄り添った形式にするほうが、結果として必要なコード量が少なくなるだけでなく、アーキテクチャ上も高凝集・疎結合を保ちやすくなる。
リファレンスを利用した結合を使ってみる。遅いとかの問題が生じたら非正規化する。
profile:{
ref:/database/default/documents/publicprofiles/<uid>,
displayName:'つぶあん',
photoURL:'https://cdn.shiodaifuku.io/images/...'
},
text:'世界一の塩大福です',stars:5,createdAt:2019081200:00:00,upd非正規化。ref 先が更新されたら一緒に更新するようなバックグランド関数を用意する。（cloud functions hook で）
・Collection へのインサートには 1 秒間 500 回の制限があり
複合インデックス
FirebaseError: The query requires a COLLECTION_GROUP_ASC index for collection ${collectionName} and field ${FieldName}. You can create it here: https://sample.comみたいな感じで言われる。のでインデックスを作る。
参考 : https://qiita.com/1amageek/items/d606dcee9fbcf21eeec6