2

I am in the process of evaluating MongoDB and writing some basic PHP applications around it. Typically in my PHP/MySQL applications, I would create an ID field and set it to auto-increment on each row insert. I would then use this ID to relate to/join tables together.

However in MongoDB, there is no auto-increment (unless you create function to do it, I believe), only an objectID. Because of this, i'm unsure of how to relate collections together.

Is it worth writing an auto-increment function (as explained here: http://docs.mongodb.org/manual/tutorial/create-an-auto-incrementing-field/), or is it common practice to store the ObjectID?

An example would be the following MySQL query:

SELECT * FROM cars WHERE car_type = '2' 

But in MongoDB....

db.cars.find( { car_type : 507c35dd8fada716c89d0013 } );

Is the above standard practice? Am I using Mongo incorrectly by creating an auto-increment field?

Darius

EDIT: I think I am so deeply rooted in MySQL that I can't imagine an application without auto-incrementing IDs. Is it safe to store objectIDs (just as you would store a MySQL AI ID)? Is this bad for readability, since you would have to look up that objectID just to see what it relates to?

  • MongoDB ObjectIDs also consists a 4-byte value representing the seconds since the Unix epoch, it is kind an auto increment, you can test it by typing ObjectId("5889ff55736a51703194b3ce").getTimestamp() returns ISODate("2017-01-26T13:53:25Z") , of course it is not exactly an auto increment id but it is ordered already (I don't know what happens if server time changes) – endo64 Jan 26 '17 at 14:48
1

In MySQL, or almost any other RDBMS, it is common to have an ID for the row (object), so you use it in other tables to make a link between the tables (Relations, or PK and FK if you prefer). This is part of the normalization process that is recommended for most types of DB design [there are exceptions though].

In MongoDB however, the general way or design is to denormalize. i.e. the document (row) is stored with all its related objects.

To make it more clear:

In MySQL you would have two tables: cars and car_types. In cars you only store the ID of the type of this car.

In Mongo DB, you would have one collection called cars, and the document in this collection would have a sub-document that contains the type's info. (You still can have a separate collection for types, but you don't store only objectID in car's collection)

HTH

  • If I create a sub document with the type's info, wouldn't that result in duplicate data (assuming I would be doing this for each 'car' document)? Thanks! – Darius Nov 18 '14 at 18:36
  • Actually, cars and car_types is about the perfect example for linking. – Markus W Mahlberg Nov 18 '14 at 18:58
  • 1
    @Darius, Yes, that will result in duplicate data, and that is what de-normalization is. Design philosophy is different here is 'document store' DBs – Jehad Keriaki Nov 18 '14 at 19:39
1

The query

db.cars.find( { "car_type" : 507c35dd8fada716c89d0013 } );

actually would be used and imho is the best solution in this case. In order to make this query efficient, however, you would create an index

db.cars.ensureIndex({"car_type":1})

In this case, linking two documents makes sense. There are other relations in which embedding documents might be the better choice. For details, please see the MongoDB docs regarding data modelling for details.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.