1

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!

Michael
  • 84
  • 8

1 Answers1

5

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.

Abe Haskins
  • 1,378
  • 1
  • 7
  • 9
  • Sorry for missing the .set(true) bit. Makes perfect sense now. Thanks so much for clarifying this for me! – Michael Jan 28 '14 at 17:55
  • What should I do if I rename the "comment1" to "comment2" for example? (in my case, the username can be renamed) – Bruno Lemos Sep 21 '14 at 04:55
  • The trick there would be to use a unique user identifier which isn't a username. You could user ref.push().name() to get a GUID-like string which you would use in place of "user1" then if the username changes, change a username field on that object instead of the GUID. – Abe Haskins Sep 26 '14 at 04:56
  • Another doubt I have on the same is how does this scale. Say, I am using a mobile app and using an Object to serialize the Users, Comments, etc. when I read the object, the comments array could be super huge. What if there are thousands of comments, will it all be fetched? Won't it create a mess? – Codevalley May 26 '16 at 10:09