Firebase - 了解非规范化数据结构答案

【问题标题】：Firebase - Understanding the Denormalized Data StructureFirebase - 了解非规范化数据结构
【发布时间】：2017-04-04 02:54:25
【问题描述】：

我正在敲定我的 Firebase 的结构，并想确定我将在早期采用最简单和最具可扩展性的设计。

要求

一个用户可以拥有许多喜欢的球队
一个团队可以有很多用户收藏它（收藏夹）

这是我当前的数据结构

firebase
--team-favoritees
--teams
--user-favorites
--users

我读过的关于 Firebase 结构的大多数帖子都有更多这种结构

firebase
--teams
----favoritees
--users
----favorites

但是，我还阅读过 Firebase 应该尽可能非规范化，这就是为什么我将数据结构化为具有少一个嵌套节点的原因。

话虽这么说- 我的设计有什么缺点吗？如果我不必更深入地挖掘一个额外的节点，可能会为简单的事务提取不需要的记录，那么同时更新多个节点会不会更容易？是否推荐一种设计而不是另一种？

感谢任何输入！

【问题讨论】：

这个问题很模糊。我认为这是一个很好的尝试。要正确回答，我们需要了解您的用例； 同时更新多个节点是什么意思？您的数据如何交互？您需要运行什么样的查询。所有这些使每个用例都不同。例如，一个团队可以有很多喜欢它的用户。达到什么目的？我们需要知道什么？您可以查询拥有某个喜欢的团队的所有用户。或者，您可以从团队、用户节点读取用户列表。更多信息会有所帮助。
我说，收藏夹只需要一个“表”，就像在传统 SQL 数据库中表示它一样：通过添加一个表 users_to_teams，它只表示该特定关系的键。
@syslogic firebase 是一个 nosql 数据库，因此它不具备 SQL 数据库将实现的关系表的概念。在处理 nosql 时，最好对数据进行非规范化，即使它引入了一些冗余，都是为了更有效的读取操作/更少的 IO
@KuraiBankusu 感谢您对我的教育，虽然我知道这一点，但显然您不明白我想说什么......而不是将所有钥匙塞进一张“桌子” （虽然您实际上建议创建大量重复项），但可以将所有键填充到他们自己的“表”中，然后简单地通过键查找......在两个方向上存储键与键的关系没有任何进步，而一个必须同时维护...您的结构从根本上是有缺陷的，因为团队可能没有最爱（人们会假设）。
团队有“收藏夹”，或者收藏了他们的用户，如果不清楚的话

标签： javascript firebase firebase-realtime-database

【解决方案1】：

transaction 有特定的含义（它是它自己的方法）。如果你的意思是update，我知道they show how 发送多个“命令”，如果你愿意，

  // Write the new post's data simultaneously in the posts list and the user's post list.
  var updates = {};
  updates['/posts/' + newPostKey] = postData;
  updates['/user-posts/' + uid + '/' + newPostKey] = postData;

我想其他方法（例如transaction）支持将这种“命令堆叠”到单个更新对象中。

关于数据结构/非规范化，他们为我遵循的“可扩展数据”提供a specific example。

【讨论】：