澄清在Firebase非规范化博客文章 [英] Clarification On Firebase Denormalization Blog Post

问题描述

我刚刚阅读了Firebase博客文章，标题为反规范化您的数据是正常的，我有要求澄清。

我一直在考虑，直到考虑段落。具体来说，如下： /评论 - 只要你在你的代码中的其他地方发现了一个不存在于/注释中的注释ID，你可以认为它已被删除，并正常进行

修改，为什么我不必修改存储在/ links和/ users下的重复注释？

对于删除，我的理解是正确的：一旦删除评论我必须在所有我的逻辑读取逻辑来交叉检查/评论的情况下，它被删除？

谢谢！

/ comments 下存储注释，然后将 / links 和 / users 。这些函数作为指向实际注释数据的指针。

请考虑帖子的示例结构...

 {
 users：{
 user1：{
 name：Alice，
 comments：{
 comment1：true 
 $ b $ 
 
 $ {
} {
 body：This is awesome！，
 author：user1 
 
 
 
 
 
 $ b注意实际的评论数据只存储一次。 
 $ b 
如果我们修改 / comments / comment1 ，我们不需要更新任何东西，因为我们只存储在 / links 和 / users 下注释的 name ，而不是实际的评论内容。
 
 
 
如果我们要删除 / comments / comment1 的评论数据。不过，我们仍然在 / users / user1 / comments 下有 comment1 这些悬挂引用。假设我们删除 / comments / comment1 ，当我们尝试加载Alice的评论时，我们可以看看那个 comment1 不存在了。然后，我们的应用程序可以通过a）删除引用，或b）忽略引用，而不是试图显示已删除的注释来做出相应的反应。
I just read the Firebase blog post titled Denormalizing Your Data Is Normal, and I have request for clarification.

I was with it until the Considerations paragraph.  Specifically, the following:

"Modification of comments is easy: just set the value of the comment under /comments to the new content. For deletion, simply delete the comment from /comments — and whenever you come across a comment ID elsewhere in your code that doesn’t exist in /comments, you can assume it was deleted and proceed normally"

For modifications, why don't I have to modify the duplicate comments stored under /links and /users?

For deletions, am I correct in my understanding that once I delete a comment I have to have logic in all my read logic to cross-check /comments in case it was deleted?

Thanks!
解决方案
The structure detailed in the blog post does not store duplicate comments. We store comments once under /comments then store the name of those comments under /links and /users. These function as pointers to the actual comment data.

Consider the example structure from the post...
{
  users: {
    user1: {
      name: "Alice",
      comments: {
        comment1: true
      }
    },
  },
  comments: {
    comment1: {
      body: "This is awesome!",
      author: "user1"
    }
  }
}
Note that the actual comment data is only stored once. 

If we modify /comments/comment1, we don't need to update anything else because we only store the name of the comment under /links and /users, not the actual comment contents.

If we were to remove /comments/comment1, that would remove the only existence of the comment data. However, we still have these "dangling" references to comment1 under /users/user1/comments. 

Imagine we delete /comments/comment1, when we try to load Alice's comments, we can look and see that comment1 doesn't exist anymore. Then our application can react accordingly by either a) deleting the reference or b) ignoring the reference and not trying to display the deleted comment.

                        
这篇关于澄清在Firebase非规范化博客文章的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！