防火墙数据库结构

Question

我才刚开始试用Firebase。当您习惯于关系数据库时，这是一个真正的麻烦！

我正在设计一个应用程序，允许用户按条形码或名称搜索膳食，并检索卡路里的数量。另外，我需要能够存储用户所吃的食物，并最终检索用户每天、每周或每个月所吃的食物。

我在想，每顿饭都会有一个唯一的ID (例如，必胜客的M1234 )，然后我会有两个查找部分--一个按条形码，一个按名字，这样就有希望涵盖搜索功能。

每个用户都会将所吃的食物存储在吃过的“表”中(在Firebase数据库中，“table”的正确术语是什么？)到了日期，只是用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"

如您所见，餐饮节点包含每个用户的餐饮事件(因此所有餐饮事件都在一个节点中)。

这使您能够查询所有类型的内容：

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.

一个遗漏是寻找包含两顿饭的就餐，然而，解决办法也在这个答案中。

总之，你的结构是健全的-只是需要稍微调整一下。

Answer 2

这个结构看起来很好(虽然我会让firebase生成ids)。唯一不能像你期望的那样工作的就是搜索。根据您的数据，如果我搜索pizza，您就无法编写返回必胜客条目的查询。我的建议是要么使用Algolia (或类似的东西)进行搜索，要么使用名称为lowerCased的另一个密钥来使查询工作成为可能。运行自己的程序唯一的问题是，您将无法搜索像izz这样的东西并让Pizza出现。关于如何进行搜索，请参见我的答案Firebase - How can I filter similarly to equalTo() but instead check if it contains the value?。