您将需要利用.childByAutoId父键名称。***的做法是从父节点中取消关联您的子数据，并允许Firebase为父节点创建随机键，这样做将起作用。

创建一个/ users节点，每个用户的父节点将是用户首次创建时由Firebase创建的uid。

在您的原始结构中，条形码和名称查找，我已集成到以下结构中以降低复杂性。

  users 
 uid_0 
 name：Mary Chen，
电子邮件：mary@chen.com
 uid_1 
名称：Larry David
电子邮件：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 
用户：uid_1 
 uid_timestamp：uid_1_ 20161207173000
 

以及用户可以选择的餐食

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

b $ b

如您所见，餐饮节点包含每个用户的餐饮活动（因此所有的用餐活动都在一个节点）

您可以查询各种事物：

 所有用户的日期或日期范围内的所有餐饮。 
包含一定饭菜的所有餐饮
用户的所有餐食
  - >酷的<  - 在一个日期范围内为特定用户的所有餐饮。 
 

一个省略是搜索包含两餐的用餐，然而，

总而言之，你的结构是完美的 - 只需要一点调整。

I'm just starting to experiment with Firebase. It's a real head bender when you're used to relational databases!

I'm trying to design an app that will allow users to search for meals by barcode or name and retrieve the number of calories.

Additionally, I need to be able to store the meals eaten by a user, and finally retrieve the food eaten by a user each day, week or month.

I was thinking each meal would have a unique ID (e.g. M1234 for Pizza), then I'd have 2 lookup sections - one by barcode and one by name, so that should hopefully cover the search functionality.

Each user would have the meals eaten stored in the eaten 'table' (what is the correct term for 'table' in a Firebase database?) by date, just referencing the meal by ID.

This is how I've designed the database.

  {
// 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"
      }
    }

  }

Does it seem reasonable or are there any obvious flaws?

Thanks for looking

Damian

You will want to leverage .childByAutoId() and let Firebase create the parent key names. It's best practice to disassociate your child data from the parent node and allowing Firebase to create 'random' key's for the parents will make that work.

Along with that, it's customary to create a /users node and the parent nodes for each user would be the uid which was created by Firebase when the user was first created.

In your original structure, there's a barcode and name lookup which I have integrated into the following structure to reduce complexity.

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

and then the dining

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"

and the meals the user can choose from

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

As you can see, the dining node contains a dining event for each user (so all of the dining events are in one node)

This enables you to query for all kinds of things:

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.

The one omission is a search for dining that contains two meals, however, the solution to that is also in this answer.

All in all, your structure is sound - just needs a little tweaking.