How to construct this database in mongodb?

Question

say i have two collections in mongodb,one for users which contains users basic info,and one for apps which contains applications.now if users are allowed to add apps,and the next time when they login, the web should get the user added app for them.how should i construct this kind of database in mongodb.

users:{_id:ObjectId(),username:'username',password:'password'}
apps:{_id:ObjectId(),appname:'',developer:,description:};

and how should i get the user added app for them??? should i add something like addedAppId like:

users:{_id:ObjectId(),username:'username',password:'password',addedApppId:[]}

to indicate which app they have added,and then get the apps using addedAppId ???

Answer 1

Yep, there's nothing wrong with the users collection keeping track of which apps a user has added like you've indicated.

This is known as linking in MongoDB. In a relational system you'd probably create a separate table, added_apps , which had a user ID, app ID and any other relevant information. But since you can't join, keeping this information in the users collection is entirely appropriate.

From the docs :

A key question when designing a MongoDB schema is when to embed and when to link. Embedding is the nesting of objects and arrays inside a BSON document. Links are references between documents.

There are no joins in MongoDB – distributed joins would be difficult on a 1,000 server cluster. Embedding is a bit like "prejoined" data. Operations within a document are easy for the server to handle; these operations can be fairly rich. Links in contrast must be processed client-side by the application; the application does this by issuing a follow-up query.

(this is the extra bit you'd need to do, fetch app information from the user's stored AppId .)

Generally, for "contains" relationships between entities, embedding should be be chosen. Use linking when not using linking would result in duplication of data.

...

Many to many relationships are generally done by linking.