Firebase Realtime Databaseでのデータ構造ごとのメリット・デメリット

Question

Firebaseを使ってユーザーごとのデータを管理するアプリを作ろうとしているのですが、データ構造を下記のいずれにしようか迷っています。
公式ガイドでは案２のようにネストを浅く保つことが薦められていますが、他ユーザーのデータにアクセスすることがないようなアプリであれば案１でも特に問題がないようにも思えます。
明確にこちらがよいという理由が思い浮かばず、決めかねているのですが、それぞれを採用する場合のメリット・デメリットを教えていただけるとありがたいです。
よろしくお願いします。

---

2017-04-04 追記
案２のような構造にした場合、ユーザーごとのデータはユーザーしか閲覧できないように権限を設定すると、セキュリティルールの仕様上、一覧を取得できなくなるので、案２を改造しました。

######案１
ユーザーのIDがルート直下にあって、それぞれのユーザーIDの配下に各種データ構造を持たせる。

{
  "user_id_1": {
    "diaries": {
      "diary1": { ... },
      "diary2": { ... },
          ...
    },
    "todos": {
      "todo1": { ... },
          ...
    }
  },
  "user_id_2": {
    "diaries": {
      "diary1": { ... },
      "diary2": { ... },
          ...
    },
    "todos": {
      "todo1": { ... },
          ...
    }
  },
      ...
}

######案２
各データ構造のデータごとにユーザーのIDを持たせる。

{
  "diaries": {
    "diary1": {
      "user_id": " ... ",
      "details": " ... "
          ...
    },
    "diary2": {
      "user_id": " ... ",
      "details": " ... "
          ...
    },
  },
  "todos"; {
    "todo1": {
      "user_id": " ... ",
          ...
    },
  },
      ...
}

**追記）**これだと各データはそのユーザーにしかアクセスできないようにルールを設定した場合、/diariesや/todosでデータの一括取得ができなくなる。（Firebaseガイド：ルールはフィルターではない）
なのでこうする必要がある。こうすれば/diaries/[user_id]でユーザーごとのデータ一覧が取得できる。

{
  "diaries": {
    "user_id_1": {
      "diary1": {
        "user_id": "user_id_1",
        "details": " ... "
          ...
      },
      "diary2": {
        "user_id": "user_id_1",
        "details": " ... "
            ...
      },
    },
    "user_id_2": { ... },
  },
  "todos"; {
    "user_id_1": {
      "todo1": {
        "user_id": "user_id_1",
            ...
      },
    },
  },
      ...
}

Answer 1

_	メリット	デメリット
案１	コードが書きやすい 自分の日記やTodoだけ見る仕様において、アプリを実行しているユーザーの日記やTodoだけ絞って取るコードが書きやすい。	拡張性が低い もし万が一今後、日記に他ユーザーが良いね出来るといった仕様が付いた際に、良いね数が多い順に並べ替える操作がしにくい。
案２	拡張性が高い もし万が一今後、日記に他ユーザーが良いね出来るといった仕様が付いた際に、良いね数が多い順に並べ替える操作がし易い。（インデックスを貼るだけでいいので）	設定の手間が増える アプリを実行しているユーザーの情報だけ絞るために、user_idにインデックスを貼る必要があるので、手間がかかる。（貼らないとレスポンスが遅い。）

という感じの印象なので、拡張性という点で案２のほうが良さそうな気がしますね。

もちろんこのサービスが今後そういう機能拡張を絶対しないと言い切れるのであれば、案１で問題ないと思います。

（なんとなくの気分で、表形式で書いてみました。見づらかったらスミマセン。。。）

Comments

[退会済みユーザー]

ご回答ありがとうございます。
たしかにユーザーを横断的に操作する機能は作りにくくなりますよね。
その辺はおっしゃられているように、今後の仕様の見通しに大きく左右されるということですね。

表形式で非常に見やすいです。ありがとうございます。

Answer 2

FirebaseではFan-outテクニックを推奨しており、データの取得時のパフォーマンスがよくなるようにデータの重複を適宜行うようにする方法がよいようです。こちらの内容が参考になりました。

ですので、とりあえず案１で進めていき、ユーザーを横断するような操作が必要になったときは下記のような構造を別に用意して対応しようと思います。

{
  // 案１の通り、ユーザーIDをキーに、各ユーザーのデータを個別に丸ごと格納する
  "user_id_1": { user_id_1のユーザーのデータ },
  "user_id_2": { user_id_2のユーザーのデータ },

  // [user_id]/diaries以下の内、他ユーザーにも公開する設定のもののコピーを登録する
  "public_diaries": {
    "diary1": {
      "user_id": "user_id_1",
      "public": true,
      "star_count": 0,
        ...
    },
    "diary2": {
      "user_id": "user_id_1",
      "public": true,
      "star_count": 10,
        ...
    },
  }
}

ありがとうございました。