问题描述
我正在努力思考如何为 firebase 实时数据库构建我的数据.我阅读了
我的问题是，您如何将用户信息(名字、姓氏、小头像)与故事相关联?
我的想法:
在故事中放置一个 user_id，其中包含特定用户的外部 ID.要加载故事，我们必须向数据库发出两个请求，一个用于获取故事，另一个用于用户.
{用户 ID : 'XYZ',文字:'foobar'，时间戳:...}
在故事中放入名字、姓氏和小头像.只需一个请求即可显示故事.但是我们必须更新每个用户的故事，例如个人资料图片更改.
{用户 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:
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: ...}
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 实时数据库的数据结构?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！