FireStoreの設計についての議論

[KinjiKawaguchi]

オプション 1: ネストされたデータ構造

このオプションでは、User、Statuses、Goal、TaskQuestTask、Tag すべてを単一の User ドキュメント内でネストさせます。
/users
/{userId}
- id
- name
- createdAt
- Tags
- Statuses
- Status
- id
- name
- Goals
- Goal
- id
...
...
...
...

メリット:
単一のドキュメント読み取りで関連するすべての情報にアクセス可能。
デメリット:
Firestore ドキュメントにはサイズ制限（1MB）がある。
ネストされたデータの更新やフィルタリングが複雑。

オプション 2: 分離されたコレクションとサブコレクション

このオプションでは、各エンティティを独自のコレクションまたはサブコレクションとして分離します。
/users
/{userId}
- id
- name
- createdAt
- Tags
/Statuses
/{statusId}
- id
- name
/Goals
/{goalId}
- id
- name
/Tasks
/{taskId}
- id
...

/tags
/{tagId}
- id
- name
- color
- createdAt
- updatedAt

メリット:
柔軟性が高く、各コレクションで独自のセキュリティルールやインデックスを設定可能。
デメリット:
関連するデータを一度に取得するには、複数のクエリまたはトランザクションが必要。

オプション 3: ハイブリッド

特定のフィールド（例えば、頻繁に更新されるもの、またはサイズが大きいもの）を分離し、残りはネストさせます。
/users
/{userId}
- id
- name
- createdAt
- Tags
/Statuses
/{statusId}
- id
- name
/Goals
/{goalId}
- id
...

[KinjiKawaguchi]

MySQL（および他のリレーショナルデータベース）に近い構造を望むなら、オプション 2（分離されたコレクションとサブコレクション）が最も近い。リレーショナルデータベースのテーブルと同じように、各エンティティ（User, Status, Goal, TaskQuestTask, Tag）が独立したコレクションとして存在させる。

以下イメージ

/users -> Usersテーブル
/{userId}
- id
- name
- createdAt
- Tags
/Statuses -> Statusesテーブル
/{statusId}
- id
- name
/Goals -> Goalsテーブル
/{goalId}
- id
- name
/Tasks -> TaskQuestTasksテーブル
/{taskId}
- id
...

/tags -> Tagsテーブル
/{tagId}
- id
- name
- color
- createdAt
- updatedAt

[KikyoNanakusa]

Unity視点だとGoalとTaskはネストしてたほうが使いやすそう打と思いました。
他はあんまりアクセスしないと思うので分離しちゃってもいいと思います

[koto623]

私もGoalsとTasksはネストしていたほうがいいのではないかと思います。tagは独立した子なので分離させるべきだと思います。

[KinjiKawaguchi]

ではそのように設計することにします。
Yahooのコミュニケーターさんにレビューをお願いしてみるかもしれません。
当然、お忙しいと思いますのでダメ元です。