如何对firebase实时数据库的数据结构进行非规范化/规范化? [英] How to denormalize/normalize data structure for firebase realtime database?

查看:16
本文介绍了如何对firebase实时数据库的数据结构进行非规范化/规范化?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在努力思考如何为 firebase 实时数据库构建数据.我阅读了

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

我的想法:

  1. 在包含特定用户的外国 id 的故事中放置一个 user_id.要加载故事,我们必须向数据库发出两个请求,一个用于获取故事,另一个用于用户.

    {user_id : 'XYZ',文本:'foobar',时间戳:...}

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

    {user_id : 'XYZ',名字:'桑德拉',姓氏:'亚当斯',smallProfilePicutre: '...',文本:'foobar',时间戳:...}

因此,当创建的故事很少而大部分时间只有阅读时,方法 1. 会很昂贵,因为我们需要支付两次阅读来显示一个故事.方法 2. 会更具成本效益.

我想在这里谈谈您对此的想法和想法.

解决方案

我和 Jay 在一起:你的问题已经基本掌握了.我们在使用 Firebase 数据库时推荐的做法的精彩总结.

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

我看到的大多数开发人员都会将个人资料信息分开,并将用户 UID 作为非托管外键保留在帖子中.这样做的好处是,当用户配置文件发生变化时,只需要在一个地方更新它.读取单个故事的性能并不算太差:两次读取相对较快,因为它们通过相同的连接.当您显示故事列表时,它出乎意料地快,因为 Firebase 通过其单个连接对请求进行管道传输.

但我帮助的第一个更大的实现实际上是在故事中复制了用户数据.正如您所说:在这种情况下,阅读故事或故事列表的速度尽可能快.当被问及他们如何处理故事中的用户信息时(请参阅策略 这里),他们承认他们没有.事实上:他们为每个故事需要历史用户信息提出了许多充分的理由.

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

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

I am trying to wrap my head around how to structure my data for firebase realtime database. I read the docs and some other questions on SO finding following advices:

  • data should be as flat as possible
  • be expensive on writes to have cheap reads
  • avoid nesting data
  • duplication of data may be okay

Keeping this in mind let me describe my specific use case. Frist there is user with following attributes:

  • Firstname
  • Lastname
  • Profile picture (big)
  • Profile picture (small)

A user may create a story, that consist of following attributes:

  • User
  • Text
  • Timestamp

The visual representation of a story may look like this:

My question is, how would you associate user information (firstname, lastname, small profile picture) with a story?

What I thought about:

  1. put a user_id in the story that contains the foreign id to the specific user. To load the story we would have to make two request to the database, one to get the story and one for the user.

    { user_id : 'XYZ', text: 'foobar', timestamp: ... }

  2. put firstname, lastname and small profile picture in the story. Only one request would be necessary to display the story. But we would have to update each user's story, when e.g. the profile picture changes.

    { user_id : 'XYZ', firstname: 'sandra', lastname: 'adams', smallProfilePicutre: '...', text: 'foobar', timestamp: ... }

So when there are few stories created and most of the time there are just reads, approach 1. would be expensive, because we pay for two reads to display a story. Approach 2. would be more cost efficient.

I would like to here your thoughts and ideas on this.

解决方案

I'm with Jay here: you pretty much got all of it in your question already. Great summary of the practices we recommend when using Firebase Database.

Your questions boils down to: should I duplicate my user profile information into each story? Unfortunately there's no single answer for that.

Most developers I see will keep the profile information separate and just keep the user UID in the post as a unmanaged foreign key. This has the advantage of needing to update the user profile in only one place when it changes. The performance to read a single story is not too bad: the two reads are relatively fast, since they go over the same connection. When you're showing a list of stories, it is unexpectedly fast since Firebase pipelines the requests over its single connection.

But one of the first bigger implementation I helped with actually duplicated the user data over the stories. As you said: reading a story or list of stories is as fast as it can be in that case. When asked how they dealt with keeping the user information up to date in the stories (see strategies here), they admitted they didn't. In fact: they argued many good reasons why they needed the historical user information for each story.

In the end, it all depends on your use-case. You'll need to answer questions such as:

  • Do you need the historical information for each user?
  • Is it crucial that you show the up-to-date information for a user in older posts?
  • Can you come up with a good caching strategy for the user profiles in your client-side code?

这篇关于如何对firebase实时数据库的数据结构进行非规范化/规范化?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆