Firebaseデータベース構造

Question

Firebaseを試し始めました。リレーショナルデータベースに慣れているときは、本当の頭のベンダーです！

私はユーザーがバーコードや名前で食事を検索し、カロリーの数を取得できるようにするアプリを設計しようとしています。さらに、私はユーザーが食べた食事を保管し、毎日、毎週、または毎月、ユーザーが食べた食べ物を検索する必要があります。

私は各食事にユニークなID（たとえば、ピザ用のM1234）があると思っていましたが、バーコードと名前で2つの検索セクションがあると思います。

各ユーザは、食べた 'テーブル'（Firebaseデータベースの 'テーブル'の正しい用語は何ですか？）に日付ごとに食べ物を食べさせ、IDで食事を参照するだけです。

これは私がデータベースを設計した方法です。

{ 
// Here are the users. 
    "users": { 
     "mchen": { 
     "name": "Mary Chen", 
     "email": "mary@chen.com", 

     } 
     }, 
     ... 
    }, 
// Here are the meals eaten by date. 
    "eaten": { 
     "mchen": { 
     // index Mary's meals in her profile /eaten/mchen/meals/20161217 should return 'M1234' (pizza) and 'M8765' (chips) 
     "meals": { 
      "20161217": { 
      "M1234": true, 
      "M8765": true 
      }, 
      "20161218": { 
      "M2222": true, 
      "M8765": true 
      } 
     }, 
     ... 
    }, 
// Here are the meals with calorie information. 
    "meals": { 
     "M1234": { 
     "name": "Pizza" 
     "calories": 400 
     }, 
     "M2222": { 
     "name": "Curry" 
     "calories": 250 
     }, 
     "M8765": { 
     "name": "Chips" 
     "calories": 100 
     }, 
    }, 
// Here is the barcode lookup 
    "barcode-lookup": { 
     "12345678": { 
     "id": "M1234" 
     }, 
     "87654321": { 
     "id": "M2222" 
     }, 
     "11223344": { 
     "id": "M8765" 
     } 
    }, 
// Here is the name lookup 
    "name-lookup": { 
     "Chips": { 
     "id": "M8765" 
     }, 
     "Pizza": { 
     "id": "M1234" 
     }, 
     "Curry": { 
     "id": "M2222" 
     } 
    } 

    } 

明らかな欠陥がありますか？

Answer 1

.childByAutoId（）を利用し、Firebaseが親キー名を作成するようにしたいと思うでしょう。親ノードから子データの関連付けを解除し、Firebaseがその親のために「ランダム」キーを作成できるようにするのがベストプラクティスです。

それに加えて、/ usersノードを作成するのが慣例であり、各ユーザーの親ノードは、ユーザーが最初に作成されたときにFirebaseによって作成されたuidになります。

元の構造には、複雑さを軽減するために以下の構造に統合したバーコードと名前のルックアップがあります。

users 
    uid_0 
    name: "Mary Chen", 
    email: "mary@chen.com" 
    uid_1 
    name: "Larry David" 
    email: "ldavid@david.com" 

、その後、ダイニング

dining 
    -Yuiia09skjspo 
    dining_timestamp: "20161207113010" 
    Y79joa90ksss: true 
    Yjs9990kokod: true 
    user: uid_0 
    uid_timestamp: "uid_0_ 20161207113010" 
    -Yi9sjmsospkos 
    dining_timestamp: "20161207173000" 
    Y79joa90ksss: true 
    Yjs9990kokod: true 
    user: uid_1 
    uid_timestamp: "uid_1_ 20161207173000" 

とあなたが見ることができるように、ユーザが

meal 
    -Y79joa90ksss 
    name: "Pizza" 
    calories: "400" 
    barcode: "008481816164" 
    -Yjs9990kokod 
    name: "Burger" 
    calories: "520" 
    barcode: "991994411815" 

から選ぶことができ、食事、ダイニングノードは、各ユーザのためのダイニングイベントが含まれています（そうすべての食事イベントは1つのノードにあります）

これにより、すべての種類のものを照会できます。

All dining for all users by date or range of dates. 
All dining that contain a certain meal 
All meals by a user 
->The cool one<- all dining for a specific user within a date range. 

1つの省略は、2つの食事を含む食事の検索ですが、その解決方法もこの回答に含まれています。

あなたの構造は健全です。ちょっとした調整が必要です。

Answer 2

構造はうまく見えますが（firebaseがidを生成させるようにしていますが）。あなたが期待しているように動作しないのは、検索だけです。あなたのデータに基づいて、pizzaを検索した場合、ピザのエントリを返すクエリを書くことができませんでした。私の提案は、Algolia（または類似のもの）を検索するために使用するか、クエリーが機能するように名前をlowerCasedにして別のキーを移動することです。あなた自身を実行する唯一の問題は、izzのようなものを検索することができなくなり、ピザが上がることです。検索方法については、私の答えFirebase - How can I filter similarly to equalTo() but instead check if it contains the value?を参照してください。