firestoreのデータ構造設計

firestore のデータのベスト・プラクティスのベスト・プラクティスについて

リレーションシップの種類

https://scrapbox.io/files/609130f09e2d6500225c805c.png

1:1

Key

ある情報を ID をもって示す

Reference

ある情報をパスをもって示す

深いネスト構造に強い

パスに version などを含めることができる

Same ID

別々のパスに同じ ID を含める

sub collection を使った方法

code:path

/version/1/user/:user_id/ // 一般公開

/version/1/user/:user_id/secure/:id // 秘密

Same ID 構造

code:path

/version/1/user/:user_id // user が操作できる

/version/1/social/:user_id // システムが操作する

分けるメリット

特定のデータを cloud functions で操作するとき、その特定のデータを別のパスにすることで functions の発火回数を抑えることができる

1:N

Key Query

where を使うやつ

検索することで関係性を持つ、ということ？

Read のセキュリティルールは、検索するために全員に公開する必要あり

Sub Collection

セキュリティの設定が簡単

自分以下でしか検索ができない

Collection Group

Sub Collection とは違い、コレクションをまたがって検索できる

N:N

Junction Collection

中間テーブルをもつ方法

Reference Collection

Sub Collection を利用した方法

Duplicated Collection

双方にデータをいれる

検索時は s/Collection/Table/g で検索するとよい

Cloud Functions で操作 vs SDK で操作

Cloud Functions

セキュリティルールを無視できる

工数がかかる

SDK

簡単

使えるなら使いたい

その他 Best Practice

Kill switch を設ける

firestore は停止することができない

バージョンアップートの有無などを記録するべき

データ構造

階層的なデータ構造（Sub Collection）がおすすめ

上位階層をドメインで切る

code:js

// 公開ユーザと非公開ユーザ

/public/v1/users/:uid

/public/v1/posts/:post

// こういうこと

/Domain/Version/CollectionID/DocumentID

モデル

NoSQL ではデータの冗長化は許容したほうがいいことも