技術記事

メディカルサークルでは、ノートを「大学 > 学年 > 科目」の3階層で整理できます。
この階層をどうデータモデリングするかは、後の検索や横断機能の自由度を大きく左右する重要な設計判断でした。
ここでは Firestore 上の実装方針と、選択の背景を整理します。

サブコレクションを使わずフラットなコレクションに揃える

files コレクション 1 本に university / grade / subject をフィールドとして持たせるフラット構成にしました。
理由は 2 つあります。
1 つは「他大学のノートを横断検索したい」という要件で、サブコレクション構成だとコレクショングループクエリが必須になり、設計の自由度が落ちるからです。
もう 1 つは「科目名は固定マスタではなく、ユーザーが自由入力する」必要があり、サブコレクションの親 ID として固定化するには向かないと判断したためです。

マスタ + 自由入力のハイブリッドで取りこぼしを防ぐ

大学と科目は、アプリ内に主要なものを初期リストとしてハードコードしつつ、選択 UI の末尾に「その他」を置き、フリーテキスト入力欄を展開する構成にしました。
大学・学年・科目はすべて学校ごとに名称が違うため、マスタだけで網羅するのは現実的ではありません。
候補から選べる手軽さと、必要なときに自由に書ける逃げ道を両立させる設計です。

表記ゆれは許容し、検索側で吸収する

「解剖学」「人体解剖学」のような表記ゆれは正規化せず、ユーザー入力をそのまま保存しています。
そのうえで、検索時には Firestore の前方一致（isGreaterThanOrEqualTo）に加えてクライアント側でフリーワードフィルタをかけることで、部分一致を吸収しています。
「解剖」で検索すれば「解剖学」も「人体解剖学」もヒットするため、ユーザー側からは正規化の不在が問題にならない設計です。

複合インデックスは宣言で管理し、無音失敗を防ぐ

階層で絞り込みつつ「閲覧数順」「いいね順」で並べる検索は、Firestore の複合インデックスとの戦いになります。
必要な組み合わせは事前に宣言してデプロイで管理する方式にしました。
最も苦労したのは「インデックス未定義でもエラーが出ずに結果が無音で空になる」ケースです。
機能が壊れているのに気づけない事故を防ぐため、StreamBuilder の error ハンドラで必ず debugPrint を仕込み、新しいクエリパターンを追加したら即 firebase deploy --only firestore:indexes を CI に組み込む運用に切り替えました。

アトミックカウンタでリアルタイム集計を整合させる

いいね数や閲覧数はリアルタイムに増えるため、ドキュメントの読み書きが競合します。
ここは Firestore のアトミックインクリメントを使い、競合下でも数が崩れないようにしました。
リアルタイム集計を別コレクションに分けるかどうかは要件次第ですが、メディカルサークルの規模では同一ドキュメント内のフィールド更新で十分に応答性も整合性も保てています。

階層ナビは画面 state で持ち、データ構造から切り離す

マイファイル画面のパンくず式ナビは、Firestore の階層構造ではなく画面 state で selectedSubject を持つだけのシンプルな実装にしています。
面倒だったのは FAB の挙動で、トップ階層では汎用の「＋」ボタンを置き、科目階層では「その科目の最新ファイルから教授名・曜日・時限を自動引き継ぎしてアップロード画面に渡す」処理を組み込みました。
データ構造をシンプルに保つ代わりに、操作の文脈は UI 側で持つというトレードオフです。

まとめ

階層データの設計では「正規化するか / 許容するか」「サブコレクションにするか / フラットにするか」が常に論点になります。
メディカルサークルでは、横断検索と自由入力という要件を起点にフラット構成を選び、検索側で表記ゆれを吸収しました。
結果として、追加の階層や学校が増えてもスキーマ変更なしで対応できる柔軟さが残せています。