I'm very new to Mongo and I'm trying to understand how exactly I have to lay relations between different tables/collections.
For example the relation between a USER and his POST(S). In SQL I would make two tables and give every post the USERID of the USER.
How would I go about doing this in Mongo? Do I make 2 seperate collections, one for users and one for posts. Or do I embed the posts inside the user collection like this
Thanks!
The MongoDB way would be to imbed the posts in the USERS collection.
If you wanted to do it the relational way, you can put an OBJECTID key inside the POSTS collection and refer to that OBJECTID inside an ARRAY key in the USERS collection.
I will warn you however, that if you foresee using a lot of relational operations in your dataset MongoDB may not be the way you want to approach this. I would suggest Postgresql.
It all depends on your specific scenario and most importantly your usage patterns (your queries ultimately).
If you generally deal with users in one area of your application and posts in another then splitting them into two collections is certainly the (only) right way.
If you always need to look at posts "from the context of a user" then merging the posts into the user document is a valid approach. Be aware of the 16MB document limit, though. So if at some point a user has more than ~16MB worth of posts you have a problem that will require you to massively change things.
If your application generally focuses on posts but needs to also show e.g. the user name for a specific post then you could as well keep the user data separate from the posts but store the user name with every post a user does. In this case, if a user changes its name you will need to update all posts of that user on top of the main user record in the second collection. Mind you, data duplication is generally a necessary evil once you go fully MongoDB style.
...and there's various other shades of grey in terms of potential setups. No right or terribly wrong. Just better suited for your case of worse. ;) Like I wrote initially, it's a trade-off between aspects like write performance, read performance, ease/pain of doing analysis on your data which I would all sum up using the terms usage or data access patterns...
