如何对firebase实时数据库的数据结构进行非规范化/规范化？

Question

我试图围绕如何为firebase实时数据库构建数据。我在以下建议中阅读了docs和其他一些关于SO发现的问题：

• 数据应尽可能平坦
• 写入便宜的读取费用
• 避免嵌套数据
• 重复数据可能没问题

记住这一点让我描述一下我的具体用例。首先，用户具有以下属性：

• 姓
• 姓氏
• 个人资料图片（大）
• 个人资料图片（小）

用户可以创建一个由以下属性组成的故事：

• 用户
• 文本
• 时间戳

故事的视觉表现可能如下所示：

我的问题是，您如何将用户信息（名字，姓氏，小型头像）与故事相关联？

我的想法：

1. 将包含外部ID的故事中的user_id放入特定用户。要加载故事，我们必须向数据库发出两个请求，一个用于获取故事，另一个用于用户。

   {    user_id：'XYZ'，    文字：'foobar'，    时间戳：... }

2. 在故事中加上名字，姓氏和小型头像。显示故事只需要一个请求。但是，例如，我们必须更新每个用户的故事。个人资料图片发生了变化。

   {    user_id：'XYZ'，    名字：'sandra'，    姓氏：'adams'，    smallProfilePicutre：'...'，    文字：'foobar'，    时间戳：... }

因此，当创建的故事很少并且大部分时间只有读取时，方法1.将是昂贵的，因为我们支付两次读取来显示故事。方法2.将更具成本效益。

我想在此提出您的想法和想法。

Answer 1

我和Jay在这里：你已经在你的问题中得到了所有这些。使用Firebase数据库时我们建议的做法的完整摘要。

您的问题归结为：我应该将我的用户个人资料信息复制到每个故事中吗？不幸的是，没有单一的答案。

我看到的大多数开发人员都会将配置文件信息分开，只是将用户UID作为非托管外键保留在帖子中。这样做的好处是，当用户配置文件发生变化时，只需在一个位置更新用户配置文件。阅读单个故事的性能也不算太差：两个读取速度相对较快，因为它们通过相同的连接。当您显示故事列表时，自Firebase pipelines the requests over its single connection以来出乎意料地快了。

但是我帮助的第一个更大的实现之一实际上是通过故事复制用户数据。正如您所说：在这种情况下，阅读故事或故事列表的速度与其一样快。当被问及他们如何处理在故事中保持用户信息最新时（参见策略here），他们承认他们没有。事实上：他们提出了很多理由，说明为什么他们需要每个故事的历史用户信息。

最后，这一切都取决于您的用例。您需要回答以下问题：

• 您是否需要每个用户的历史信息？
• 在较旧的帖子中显示用户的最新信息是否至关重要？
• 您能否在客户端代码中为用户配置文件提出一个好的缓存策略？