MongoDB, using a Mongodb ObjectID between collections

Question

Using PHP and MongoDB, I have a collection called users, and the other is forms in the same database.

I use Mongodb's ObjectIDID as the user ID for documents in the form collection, storing ObjectId users as uid in every form document.

I'm going to create an index of a uid field in a form collection, but my question is, how should I save Objectid users?

At the moment I am saving it as a regular string (simplified)

$collection->insert( array('formName'=>'The name','uid'=>'CURRENT_USERS_ObjectId_AS_string') ); 

Is this like logic or is it best practice in this case to create a Mongodb object id for uid like

 $collection->insert( array('formName'=>'The name','uid'=> new MongoId('CURRENT_USERS_ObjectId_AS_string')) ); 

Answer 1

Now I am not familiar with PHP, but the circuit design you proposed is good. I use a similar structure for my C # implementation. To be clear, this is an example of my outline.

 Account Class public ObjectId Id{get;set;} public string Email {get;set} public string Password{get;set;} User Class public ObjectId Id{get;set;} public string AccountId {get;set}//refers to the ID in the account. 

Now, if I want to request an account for any user, I can simply request it using accountId in a user class.

MongoDb calls this linking technique as a manual link, and it is also the one it recommends here is the link http://docs.mongodb.org/manual/applications/database-references/

Answer 2

Using help references is excellent - even recommended. Use DbRefs if they offer certain advantages - for example, allowing automatic de-linking (a mongo script or php code can automatically know that the points foo are in the collection x, with id y [in the z database]).

Different types - poor design

However, avoid type manipulation.

Having something that is actually a foreign key in one collection, and it differs from the type of collection that it points to, is a bad design. A type of juggling is something that can be excluded from development in general, rather than introduced.

Think of a database

Code like this worked on db, should work:

 form = db.forms.findOne(); user = db.users.findOne({_id: form.user_id}); 

And it shouldn’t make any difference what type is the _id user collection field. With the schema in question, this code will look like this:

 form = db.forms.findOne(); user = db.users.findOne({_id: new MongoId(form.user_id)}); 

In fact, this is not a huge difference, but it means that you should think / remember to convert these links, and it becomes problematic if / when a collection is created that uses a different type - it introduces inconsistencies.

Consider the following:

 > school = db.schools.insert({_id: 123, name: "my school"}); > userId = new ObjectId(); > db.users.insert({_id: userId, name: "Me"}); > db.forms.insert({user_id: userId, school_id: 123}); 

Let's say that the school identifier is a unique code. if it is not possible to change this, it is appropriate and a good idea to use _id as the field. Now the school ID and user ID are different types:

 > db.forms.findOne(); { "_id" : ObjectId("508940370392baf87e68e31d"), "user_id" : ObjectId("5089401c0392baf87e68e31b"), "school_id" : 123 } 

If they are stored as-is, it is still possible to completely ignore these different types in the queries:

 form = db.forms.findOne(); school = db.schools.findOne({_id: form.school_id}); user = db.users.findOne({_id: form.user_id}); 

If different types are used, this means that there is a need to think "with this collection I need to convert the string to ObjectId, but with this I should not."

This is a problem that could have been avoided, but was introduced instead.