TOP(About this memo)) > 一覧(Firestore) > データ構造
構成要素
- https://firebase.google.com/docs/firestore/data-model?hl=ja
- コレクション - ドキュメント - データ の 構成となる。
- ドキュメント
- ドキュメントは JSON によく似ており、実際基本的には JSON と同じ。
- ただ、サイズは 1 MB までに制限、そしてデータ型がサポート。
- ドキュメントにはサブコレクションを入れることができる。
- ドキュメントIDのルール
- フィールド名のルール
- . と [ と ] と * と ` は使用しない。
- スキーマレス
- データベースレベルで、フィールド等の制限がかからない。
- 同一のコレクション内でも、それぞれのドキュメントで違うフィールドを持つことができる。
- ただ、クエリーを考えると同じフィールドを使うほうが好ましい
- 同一のフィールドでも、違うフィールドタイプの値を入れることができる。
- コレクション
- コレクションにはフィールドを含めることはできない。
- コレクションの明示的な作成、削除は不要
- 最初のドキュメントを作成するとコレクションが暗黙的に作成され、ドキュメントをすべて削除すると、コレクションも削除される。
- コレクションにサブコレクションを直接入れることはできない。コレクション>ドキュメント>コレクション>…という交互の形になる。
- リファレンス
- ドキュメントやコレクションへのリファレンスを作成することができる。
- リファレンスはそこにデータがあるかどうかにかかわらず作成できる。
- リファレンスを作成してもネットワーク操作は実行されない。
- サブコレクション
- サブコレクションは特定のドキュメントに関連付けられたコレクション
- コレクション>ドキュメント>コレクション
- サブコレクションは明示的に取得する必要がある。
- 例えば、チャットメッセージなどのデータ件数が多いものを直接ルームに入れずにサブコレクションにしておけば、ルーム一覧を取得した際にデータ量が少なくて済む。
- サブコレクションを含むドキュメントを削除しても、それらのサブコレクションは削除されない。
祖先ドキュメントが存在しない場合
コレクション、サブコレクションを削除する方法
- コレクションまたはサブコレクション内のすべてのドキュメントを取得して削除
- 大きなコレクションがある場合は、メモリ不足エラーを避けるため、小さなバッチに分けてドキュメントを削除する
構造化
- https://firebase.google.com/docs/firestore/manage-data/structure-data?hl=ja
- ドキュメント内でネストする
- シンプルである
- ただしリストが大きくなったり、増加したりすると、ドキュメントも大きくなり、検索時間が遅くなる可能性がある。
- したがって直近のデータなど、少量データを持たせておく用途が好ましい。
- サブコレクション
- リストが大きくなっても、親ドキュメントのサイズが変わらない。
- すべてのクエリ機能を使用でき、複数のサブコレクションにまたがるコレクション グループ クエリも発行できる
- サブコレクションを簡単に削除することはできない
- ルートレベルのコレクション
- ルートレベルのコレクションは、多対多の関係に適しており、各コレクション内で強力なクエリを実行できる。
- データが階層的になっていることから、データベースが拡大するにつれ、データの取得が難しくなる可能性がある。
データ型
- https://firebase.google.com/docs/firestore/manage-data/data-types?hl=ja
- ブール値、整数（64ビット符号付き）、浮動小数点（64ビット倍精度）、日時、配列、地理的座標、オブジェクト（マップ）、参照、バイト（1MiB-89）、テキスト文字列（1MiB-89）、NULL
- 地理的座標
- 日時
- 精度はマイクロ秒までになり、それより下の桁は切り捨て
- 配列
- 配列の要素として他の配列値を格納することはできない。
- マップ
- インデックス付けされている場合は、サブフィールドに対してクエリを実行できる。
- インデックス付けから除外した場合、すべてのサブフィールドもインデックス付けから除外される。
- キーの順序は常に並べ替えられる。
- 順序付けや比較はリンク先参照。