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

>数据应尽可能平坦
>写入便宜读取成本高昂
>避免嵌套数据
>重复数据可能没问题

牢记这一点让我描述我的具体用例.首先,用户具有以下属性：

>名字
>姓氏
>个人资料图片(大)
>个人资料图片(小)

用户可以创建包含以下属性的故事：

>用户
>文字
>时间戳

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

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

我的想法：

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

{
user_id：’XYZ’,
文字：’foobar’,
时间戳：…
}
>在故事中放置名字,姓氏和小型头像.显示故事只需要一个请求.但是,例如,我们必须更新每个用户的故事.个人资料图片发生变化

{
user_id：’XYZ’,
名字：’sandra’,
姓氏：’adams’,
smallProfilePicutre：’…’,
时间戳：…
}

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

我想在此就你的想法和想法.

解决方法

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

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

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

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

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

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!