Firebase数据库结构 [英] Firebase database structure

问题描述

我刚刚开始实验Firebase。当你习惯于关系数据库时，这是一个真正的弯曲！

我想设计一个应用程序，允许用户通过条形码或名称搜索膳食，检索卡路里数。

此外，我需要能够存储用户吃饭的食物，最后检索用户每天，每周食用的食物或每月。

我以为每餐都有一个唯一的ID（例如M1234的比萨饼），然后我会有2个查找部分 - 一个条形码和一个

每个用户都会在吃饭表格中存储膳食（table的正确名词是什么意思）

这是我设计数据库的方式。

  {
 //这里是用户。 
users：{
mchen：{
name：Mary Chen，
email：[e-mail]，
 
} 
}，
 ... 
}，
 //这是按日期吃的饭菜。 
eaten：{
mchen：{
 //索引玛丽在她的个人资料/ eaten / mchen / meals / 20161217应该返回'M1234'比萨饼和'M8765' （筹码）
meals：{
20161217：{
M1234：true，
M8765：true 
}，
 20161218：{
M2222：true，
M8765：true 
} 
}，
 ... 
}，
 //这里是与卡路里信息的饭菜。 
meals：{
M1234：{
name：Pizza
calories：400 
}，
M2222 ：{
name：Curry
calories：250 
}，
M8765：{
name：Chips
calories：100 
}，
}，
 //这是条形码查找
barcode-lookup：{
12345678： {
id：M1234
}，
87654321：{
id：M2222
}，
11223344 ：{
id：M8765
} 
}，
 //这是名称查找
name-lookup：{
Chips：{
id：M8765
}，
Pizza：{
id：M1234
}，
Curry：{
id：M2222
} 
} 
 
} 
  

看起来合理还是有明显的缺陷吗？

Damian

解决方案

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

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

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

  users 
 uid_0 
 name：Mary Chen，
电子邮件：[e-mail]
 uid_1 
名称：Larry David
电子邮件：[e-mail]
  

然后用餐

  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": "[e-mail]",

        }
      },
      ...
    },
// 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: "[e-mail]"
  uid_1
    name: "Larry David"
    email: "[e-mail]"

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.

这篇关于Firebase数据库结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！