Clarification in the Denormalization Firebase blog
I just read a Firebase blog post titled "Denormalizing Your Data Is OK" and I have a request for clarification.
I was with him until the paragraph "Considerations". Specifically the following:
"Modifying comments is simple: just set the comment value in a comment / comment on new content. To remove, simply remove the comment from / comments - and whenever you come across a comment id elsewhere in your code that doesn't exist in / comments, you you can assume that it has been removed and is working fine "
As far as changes go, why don't I need to change the duplicate comments stored in / link and / users?
For deletion, can I correctly understand that once I delete a comment, I must have logic in my entire read logic to cross-validate / comment in case it is deleted?
Thank!
source to share
The structure detailed in the blog post does not store duplicate comments. We save comments once under /comments
, then we save name
those comments in /links
and /users
. They act as pointers to the actual comment data.
Let's look at the structure of the example from the post ...
{
users: {
user1: {
name: "Alice",
comments: {
comment1: true
}
},
},
comments: {
comment1: {
body: "This is awesome!",
author: "user1"
}
}
}
Please note that the actual comment data is only saved once.
If we change /comments/comment1
, we don't need to update anything, because we only store the name
comments in /links
and /users
, not the actual content of the comments.
If we were to delete /comments/comment1
, it would eliminate the existence of these comments. However, we still have these dangling links to the comment1
pod /users/user1/comments
.
Imagine we delete /comments/comment1
, when we try to load Alice's comments, we can look at what comment1
no longer exists. Our application can then respond appropriately by either a) removing the link, or b) ignoring the link and not trying to display the deleted comment.
source to share