Firebaseを使ってユーザーごとのデータを管理するアプリを作ろうとしているのですが、データ構造を下記のいずれにしようか迷っています。
公式ガイドでは案2のようにネストを浅く保つことが薦められていますが、他ユーザーのデータにアクセスすることがないようなアプリであれば案1でも特に問題がないようにも思えます。
明確にこちらがよいという理由が思い浮かばず、決めかねているのですが、それぞれを採用する場合のメリット・デメリットを教えていただけるとありがたいです。
よろしくお願いします。
2017-04-04 追記
案2のような構造にした場合、ユーザーごとのデータはユーザーしか閲覧できないように権限を設定すると、セキュリティルールの仕様上、一覧を取得できなくなるので、案2を改造しました。
案1
ユーザーのIDがルート直下にあって、それぞれのユーザーIDの配下に各種データ構造を持たせる。
{
"user_id_1": {
"diaries": {
"diary1": { ... },
"diary2": { ... },
...
},
"todos": {
"todo1": { ... },
...
}
},
"user_id_2": {
"diaries": {
"diary1": { ... },
"diary2": { ... },
...
},
"todos": {
"todo1": { ... },
...
}
},
...
}
案2
各データ構造のデータごとにユーザーの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",
...
},
},
},
...
}
-
気になる質問をクリップする
クリップした質問は、後からいつでもマイページで確認できます。
またクリップした質問に回答があった際、通知やメールを受け取ることができます。
クリップを取り消します
-
良い質問の評価を上げる
以下のような質問は評価を上げましょう
- 質問内容が明確
- 自分も答えを知りたい
- 質問者以外のユーザにも役立つ
評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。
質問の評価を上げたことを取り消します
-
評価を下げられる数の上限に達しました
評価を下げることができません
- 1日5回まで評価を下げられます
- 1日に1ユーザに対して2回まで評価を下げられます
質問の評価を下げる
teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。
- プログラミングに関係のない質問
- やってほしいことだけを記載した丸投げの質問
- 問題・課題が含まれていない質問
- 意図的に内容が抹消された質問
- 過去に投稿した質問と同じ内容の質問
- 広告と受け取られるような投稿
評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。
質問の評価を下げたことを取り消します
この機能は開放されていません
評価を下げる条件を満たしてません
質問の評価を下げる機能の利用条件
この機能を利用するためには、以下の事項を行う必要があります。
- 質問回答など一定の行動
-
メールアドレスの認証
メールアドレスの認証
-
質問評価に関するヘルプページの閲覧
質問評価に関するヘルプページの閲覧
+2
_ | メリット | デメリット |
---|---|---|
案1 | コードが書きやすい 自分の日記やTodoだけ見る仕様において、アプリを実行しているユーザーの日記やTodoだけ絞って取るコードが書きやすい。 | 拡張性が低い もし万が一今後、日記に他ユーザーが良いね出来るといった仕様が付いた際に、良いね数が多い順に並べ替える操作がしにくい。 |
案2 | 拡張性が高い もし万が一今後、日記に他ユーザーが良いね出来るといった仕様が付いた際に、良いね数が多い順に並べ替える操作がし易い。(インデックスを貼るだけでいいので) | 設定の手間が増える アプリを実行しているユーザーの情報だけ絞るために、user_idにインデックスを貼る必要があるので、手間がかかる。(貼らないとレスポンスが遅い。) |
という感じの印象なので、拡張性という点で案2のほうが良さそうな気がしますね。
もちろんこのサービスが今後そういう機能拡張を絶対しないと言い切れるのであれば、案1で問題ないと思います。
(なんとなくの気分で、表形式で書いてみました。見づらかったらスミマセン。。。)
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
check解決した方法
+1
FirebaseではFan-outテクニックを推奨しており、データの取得時のパフォーマンスがよくなるようにデータの重複を適宜行うようにする方法がよいようです。こちらの内容が参考になりました。
ですので、とりあえず案1で進めていき、ユーザーを横断するような操作が必要になったときは下記のような構造を別に用意して対応しようと思います。
{
// 案1の通り、ユーザー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,
...
},
}
}
ありがとうございました。
投稿
-
回答の評価を上げる
以下のような回答は評価を上げましょう
- 正しい回答
- わかりやすい回答
- ためになる回答
評価が高い回答ほどページの上位に表示されます。
-
回答の評価を下げる
下記のような回答は推奨されていません。
- 間違っている回答
- 質問の回答になっていない投稿
- スパムや攻撃的な表現を用いた投稿
評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。
15分調べてもわからないことは、teratailで質問しよう!
- ただいまの回答率 88.33%
- 質問をまとめることで、思考を整理して素早く解決
- テンプレート機能で、簡単に質問をまとめられる
2017/03/31 18:21
たしかにユーザーを横断的に操作する機能は作りにくくなりますよね。
その辺はおっしゃられているように、今後の仕様の見通しに大きく左右されるということですね。
表形式で非常に見やすいです。ありがとうございます。