1

I saw the following code from one of the firebase example apps (Link):

// Write the new post's data simultaneously in the posts list and the user's post list.
var updates = {};
updates['/posts/' + newPostKey] = postData;
updates['/user-posts/' + uid + '/' + newPostKey] = postData;

When you add a new post, it writes the same data object into two different places. This seemed odd to me because it means now there are two exactly same data that you have to take care of if you want to update or delete them. I'd rather do something like this:

post: {
  id: 1,
  username: 'awesomeMan', // store necessary author's metadata
  title: 'hello',
  body: 'body
}

author: {
  id: 1,
  username: 'awesomeMan',
  email: 'hello@gmail.com',
  posts: {
    1: true // index posts by their ids
  }
}

If I do it this way, I still have a bit of data duplicate because I store user's metadata username inside a post. But isn't it better than having two exactly same data in two places?

Edit: Follow Up Question I want to add Comments resource to Posts. Given these two options, which one is better, and why?

Option 1.

Store all comments related to postId under this path:

/post-comments/${postId}

This is the only path for comments and we don't store anything into comments/

Option 2.

Store comments in comments/ and index them by ids in posts.

/post/${postId}/comments #only consists of commentIds that belong to this post
/comments/${commentId}
Maximus S
  • 10,759
  • 19
  • 75
  • 154
  • Please stick to a single question per post. For #1 the topic is incredibly broad, but it basically boils down to: NoSQL databases work differently from relation databases and data duplication is quite normal in them. For a great introduction, read this [article on NoSQL data modeling](https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/). – Frank van Puffelen Aug 06 '16 at 22:15
  • @FrankvanPuffelen Thank you so much! I think I will have more question on authentication later. – Maximus S Aug 06 '16 at 22:18
  • @FrankvanPuffelen After reading the document, I updated the question to add a follow-up. Do you mind taking a look at this? – Maximus S Aug 06 '16 at 23:20
  • 1
    The best solution is the one that works for all your use-cases. Since we don't know those (and likely you don't know them yet either), it is better to focus on what works for your app right now. That said: I wrote this [answer on some data modeling considerations](http://stackoverflow.com/questions/16638660/firebase-data-structure-and-url/16651115#16651115) a few years ago and it still seems helpful to many developers new to Firebase. – Frank van Puffelen Aug 07 '16 at 00:38
  • 1
    And I would go for option 2. I am a strong believer in partitioning data where possible. It often helps once you start adding security rules and makes it easier for the database to return the right results. When you make things easier on the database, it will do those things faster and scale better. – Frank van Puffelen Aug 07 '16 at 00:39
  • @FrankvanPuffelen Thank you! I will try it – Maximus S Aug 07 '16 at 04:26
  • @FrankvanPuffelen I promise this is the last question on this topic: http://stackoverflow.com/questions/38817446/firebase-nosql-denormalization-vs-indexing Thank you so so much for all your clear answers. – Maximus S Aug 07 '16 at 18:53

0 Answers0