読み込み専用のFirebase Storeのデータ設計をどうしていけば良いのか分からない

Question

前提・実現したいこと

食材の栄養素を取得して分類したデータを表示するサイトを作ろうとしていまして、そのデータ設計に悩んでいます。
DB設計は初心者ですが、NoSQLのFirebase Storeにデータを保存していい感じにデータを読み取りしていきたいと思っています。

会員登録機能を後からでも実装できる程のデータの拡張性は残しておきたいです。

悩んでいるポイント

今の所、Home画面、遷移テンプレページ各種（全部で４、５ページになりそう）のそれぞれに専用コレクションをつくり、トピック別にドキュメントを生成したデータ設計にしようと考えています。

しかし、そのような１ページにつき１コレクションなデータ設計に何か問題はないのか、もっとマシなやり方はないのかわかりません。

メジャーなSQLを扱うデータ設計であれば情報はたくさん出てくるのですがFirebase Storeに関してはまだあまり情報もないため現役でデータを触った経験のある方にお尋ねしたくて質問させていただきました。

SQL文の基本から勉強しろな案件かもしれませんが今は時間の優先順位としてはFirebaseを用いてお手軽に実装したくて選定しました。

追伸

私のようなケースにオススメの書籍やコンテンツがあれば教えていただきたいです（実践Firestore NexPublishingの書籍ならざっくりと読んだ）
使用する技術は React、Firebase、TypeScript(検討中)になります。

Comments

[hoshi-takanori]

どんなデータを保存してどのように表示したいかによると思います。自分も勉強中ですが、NoSQL は SQL のように正規化せずに、表示するデータをそのまま持つのもありみたいなので、１ページにつき１コレクションというのもありかもしれません。(でも、将来データを追加や変更する場合に困らないようにしたいですよね…。)

[moimoi_sushi]

ありがとうございます。言葉で伝えるのは難しいのですが食材の栄養素を降順に並べ替えたり、複数の栄養素を総合した形での順番の並べ替えを行ったりをページ毎で行います。
原則的には食材の栄養素データをベースにして計算して別のデータも派生して出していきページ毎に必要なデータを表示していきます。

データはほぼ確定で都度、追加（もしくは削除）していく予定です。１ページにつき１コレクションと別途、元のソースデータもFirebase Storeに保存しておき、ソースデータにデータを追加したら他の加工データも同時に算出してそれぞれのコレクションに格納する形にしたいと返信をしながら思いました。