Q&A
自分もあまり詳しくありませんが、参考になりそうなリンクを貼っておきます。
https://qiita.com/1amageek/items/d606dcee9fbcf21eeec6
https://medium.com/google-cloud-jp/firestore2-920ac799345c
https://coconala.com/blogs/1638666/40073
Firestoreを使用してSNSのようなアプリを作成しています。
Firestoreは通常のSQLと違い正規化はせず、データを冗長させて持たせた方が良いと多くのサイトにあるため、以下のようなDB構成にしています。
ですが、以下構成だと冗長して持たせているデータの生合成を保つために、ユーザ情報に更新があった場合はPostコレクション内のそれぞれで持っているユーザ情報も更新する必要があります。
前提
・料金を抑えるが管理はしやすく
・リアルタイム性はそこまで求められない
検討内容
現時点で私が考えられるのは、
①Postコレクション内のユーザ情報をreference型にしてUserコレクション内のドキュメントのパスを記載する
⇨メリット：Userコレクションを更新するだけで良い
デメリット：Postコレクション内のドキュメント読み込みとreference型のパス読み込みでアクセス数が増加する。
②Firebase CloudFunctionでトリガー設定して、ユーザ情報が書き換えられたら一括更新
③アプリ側で、ユーザ情報更新時に一括更新させる
ご相談したいこと
②③は実装方法をもう少し詳しく調べる必要がありますが、whereなどを使用して条件指定でマッチした複数ドキュメントでも実装できるのか。
①〜③で最善の方法はどれなのか。また、他に良い方法があるのか。
Firestore構成
UserCollection
1Users - document - userid 2 - userimg 3 - username...
PostCollection
1Posts - document - postid 2 - userimg 3 - username 4 - postcontent 5 - postimg...
回答1件
0
ベストアンサー
① > ② >>>>>>> ③
回答が出てないようなので、独断と偏見で答えてみました。ちなみにFirestoreは昔にちょろっと触っただけです。
Reference型が使えるのであればこれを使うのが一番良いと思います。ただ、使える条件があるようので、まずは現状の仕様に合わせてテストしてみるといいのではないでしょうか（私は使ったことないので分かりません）。
③は普通に考えてもない気がしますが、Firestoreは通常のリレーショナルDBとはかなり違うので、もしかするとそういう実装もあるのかもしれません。
Firestoreはこういう使い方には向いていないような気もするので、通常のリレーショナルDBを使うことを考えても良いかもしれませんね。
投稿2021/07/09 15:49
総合スコア4853
回答ありがとうございます。
まだ少し実装方法には迷っていますが、②の方法で試しでやってみようと思います。
①のReference型が一番実装しやすく良いのですが、タイムライン表示にユーザ名などの情報も表示する予定なので、1つの投稿を読む毎にUserCollectionのデータを取得する形になり、１つのPostDocument読むと2回アクセス。100投稿表示で200回のアクセスになってしまい、ユーザが増えると更に膨大なアクセスになりそうなので、②で実装を試してみます。
③のユーザ側で更新は、firestore のトランザクションとBatch書き込み機能がサポートされており、実装は可能ですが、複数のドキュメントをユーザ側で処理するのはネットワークエラーなどで処理が中途半端になるとデータの整合性が保てなくなってしまうため、避けるべき？と思いました。
参考：https://firebase.google.com/docs/firestore/manage-data/transactions?hl=ja
ある程度作り込んでしまっているため、慣れないFirestoreですが、このまま進めて実装してFirestoreの知見を溜めようと思います。完成後、料金の兼ね合い次第で、リレーショナルDBの移行も検討していきたいと思います。
貴重なご意見ありがとうございました。
FIrestoreのDB設計の情報が少なく困っていたので、とてもありがたいです。
ベストアンサーにさせていただきます。
あなたの回答
tips
プレビュー
