nosql - Firebase data structure and url -

i'm new in firebase , nosql bear me use reference sql. question how structure data in firebase?

in firebase, mean every "new firebase" = "new database" or "table" in mysql?

if in real time web app, have users , comments. in mysql, create users , comments table link them together.

how structure in firebase?

thank in adv

if have users , comments, model this:

root  |  +-- vzhen  |     |  |     +-- vzhen's comment 1  |     |  |     +-- vzhen's comment 2  |  +-- frank van puffelen        |        +-- frank's comment 1        |        +-- frank's comment 2 

however more there third entity, article, , users commenting on (each other's) articles.

firebase doesn't have concept of foreign key, it's easy mimic it. if that, can model user/article/comment structure this:

root  |  +-- articles  |     |  |     +-- text of article 1 (aid=1)  |     |  |     +-- text of article 2 (aid=2)  |  +-- users  |     |  |     +-- vzhen (uid=1056201)  |     |  |     +-- frank van puffelen (uid=209103)  |  +-- comments  |     |  |     +-- vzhen's comment on article 1 (cid=1)  |     |  |     +-- frank's response (cid=2)  |     |  |     +-- frank's comment on article 2 (aid=2,uid=209103)  |  +-- article_user_comment        |        +-- (aid=1,uid=1056201,cid=1)        |        +-- (aid=1,uid=209103,cid=2)        |        +-- (aid=2,uid=209103,cid=3) 

this quite direct mapping of way you'd model in relational database. main problem model number of lookups you'll need information need single screen.

1. read article (from articles node)
2. read information comments (from article_user_comment node)
3. read content of comments (from comments node)

depending on needs, might need read users node.

and keep in mind firebase not have concept of clause allows select elements article_user_comment match specific article, or specific user.

in practice way of mapping structure not usable. firebase hierarchical data structure, should use unique abilities gives on more traditional relational model. example: don't need article_user_comment node, can keep information directly under each article, user , comment itself.

a small snippet of this:

root  |  +-- articles  |     |  |     +-- text of article 1 (aid=1)  |     .    |  |     .    +-- (cid=1,uid=1056201)  |     .    |  |          +-- (cid=2,uid=209103)  |  +-- users  |     |  |     +-- vzhen (uid=1056201)  |     .    |  |     .    +-- (aid=1,cid=1)  |     .      |  +-- comments        |        +-- vzhen's comment on article 1 (cid=1)        |        +-- frank's response (cid=2)        |        +-- frank's comment on article 2 (cid=3) 

you can see here, we're spreading information article_user_comment on article , user nodes. denormalizing data bit. result we'll need update multiple nodes when user adds comment article. in example above we'd have add comment , nodes relevant user node , article node. advantage have fewer nodes read when need display data.

if take denormalization extreme, end data structure this:

root  |  +-- articles  |     |  |     +-- text of article 1 (aid=1)  |     |    |  |     |    +-- vzhen's comment on article 1 (uid=1056201)  |     |    |  |     |    +-- frank's response (uid=209103)  |     |  |     +-- text of article 2 (aid=2)  |          |  |          +-- frank's comment on article 2 (uid=209103)  |  +-- users        |        +-- vzhen (uid=1056201)        |    |        |    +-- vzhen's comment on article 1 (aid=1)        |        +-- frank van puffelen (uid=209103)             |             +-- frank's response (aid=1)             |             +-- frank's comment on article 2 (aid=2) 

you can see got rid of comments , article_user_comment nodes in last example. information article stored directly under article node itself, including comments on article (with "link" user made comment). , information user stored under user's node, including comments user made (with "link" article comment about).

the thing still tricky model fact firebase doesn't have api traverse such "links", have user/article yourself. becomes lot easier if use uid/aid (in example) name of node identifies user/article.

so leads our final model:

root  |  +-- articles  |     |  |     +-- aid_1  |     |    |  |     |    +-- text of article 1  |     |    |  |     |    +-- comments  |     |         |  |     |         +-- vzhen's comment on article 1 (uid=1056201)  |     |         |  |     |         +-- frank's response (uid=209103)  |     |  |     +-- aid_2  |          |  |          +-- text of article 2  |          |  |          +-- comments  |               |  |               +-- frank's comment on article 2 (uid=209103)  |  +-- users        |        +-- uid_1056201        |    |        |    +-- vzhen        |    |        |    +-- comments        |         |        |         +-- vzhen's comment on article 1 (aid=1)        |        +-- uid_209103             |             +-- frank van puffelen             |             +-- comments                  |                  +-- frank's response (aid=1)                  |                  +-- frank's comment on article 2 (aid=2) 

i hope helps in understanding hierarchical data-modelling , trade-offs involved.