0

I'm seeing mixed tutorials in Firebase that recommends to structure data like this:

posts: {
  post_1: {
    title: 'Some Title',

    comments: {
      comment_1: true,
      comment_2: true,
      ...
      comment_x: true
    }
  }
}

comments: {
  comment_1: {
    name: 'Foo'
  },

  comment_2: {
    name: 'Bar'
  },

  ...

  comment_x: {
    name: 'X'
  }
}

and

posts: {
  post_1: {
    title: 'Some Title',
  }
}

comments: {
  post_1: {
    comment_1: {
      name: 'Foo'
    },

    comment_2: {
      name: 'Bar'
    },

    ...

    comment_x: {
      name: 'X'
    }
  }
}

I think the latter is better in terms of speed when querying, bulk writing, and security flexibility. Especially that when you have the 1st data structure and you query over the blogs just to find out it's title. It's gonna load tons of data if you have a million comments even if the value is just true (unless I'm missing something here).

My question is, for heavy data like those in social networks, is the 2nd data structure really that better compared to the 1st one? I'm not even convinced that the 1st one is better at any area than the 2nd one at all.

I'm torn because some Firebase tutorial uses the 1st data structure and I'm using the Emberfire web library from Firebase which enforces it if you want to completely embrace the library.

Mikko Paderes
  • 830
  • 9
  • 18
  • 3
    Why wouldn't you use the second example? It's shallow(er) which is good for Firebase. The data is separated, again a good thing. The only downside (which really isn't a downside) is if you want to hit the database only once for the post and associated comments, instead of twice; once for the post and again for the comments. Obviously #1 wins there but other than that #2 ftw. – Jay Jan 13 '16 at 19:43
  • This looks like an answer, @Jay. You should post it so we can upvote. – Kato Jan 14 '16 at 00:44
  • Thanks. I was really just looking for confirmation since I thought that maybe I was just missing something. I guess I'll have to scrap emberfire for now since I think it's much more convenient for small apps where you can have the 1st data structure in my post above. – Mikko Paderes Jan 14 '16 at 01:08

1 Answers1

1

The second example is shallow(er) which is good for Firebase. The data is separated, again a good thing. The only downside (which really isn't a downside) is if you want to hit the database only once for the post and associated comments, instead of twice as in the second example; once for the post and again for the comments. Obviously #1 wins there but other than that #2 is the way to go.

Jay
  • 34,438
  • 18
  • 52
  • 81