MongoDB: storage and when to use relationships

Question

I am new to MongoDB, so please bear with me.

I have 2 questions:

First do the following:

// add a record $obj = array( "title" => "Calvin and Hobbes", "author" => "Bill Watterson" ); 

Does MongoDB save the "title" and "author" as text for each individual record of this object in this collection? Or does he create a schema and convert them to field numbers (or nothing at all and does not save purely data)?

My second question: when should I use "relationships"? Let's say I have 100 resellers that contain (one object) 1000 clients each, and each client has 10 projects. This creates manipulation for one huge common object.

In the SQL world, all of this will be related to "objects." In the world of documents, we try to save complete objects by introducing sub-objects.

However, this can be cumbersome. What is the best practice for this? Can someone point me to the guidelines, please.

Thanks.

Answer 1

Does MongoDB field names indicate for each record in this collection?

Yes, MongoDB saves text for every entry. In practice, this is usually not a big deal, if disk space is a limiting factor, you might want to consider something else.

When should you use "relationships"?

It is more an art than a science. Mongo Documentation on Schemas is a good reference, but here are some things to consider:

• Put as much as possible

  The joy of the Document database is that it eliminates many unions. Your first instinct should be to place as much as possible in one document. Since MongoDB documents have a structure, and because you can query efficiently in this structure, there is no need to immediately normalize the data, as in SQL. In particular, any data that is not useful other than its parent document must be part of the same document.

• Separate data that can be transferred from several places to your own collection.

  This is not so much a problem of "memory space" as a problem of "data consistency." If many records will refer to the same data, it will be more efficient and less error prone to update one record and keep links to it in other places.

• Document Size Information

  MongoDB imposes a 4 MB limit on a single document. In the world of GB data, this sounds small, but it is also 30 million tweets or 250 thousand typical responses or 20 flickering photos. On the other hand, this is much more information that could have been presented in due time on a typical web page. First consider what will simplify your queries. In many cases, the problem with the size of the documents will be premature optimization.

  In the example you pointed out, I would make 3 separate collections, because I do not need to know about 9 other projects in order to create a list for the project. I will keep the queries simple. (But see Protip below)

• Complex data structures:

  MongoDB can store arbitrary deep nested data structures, but cannot efficiently look for them. If your data forms a tree, forest or graph, you really need to store each node and its edges in a separate document. (Note that there are data warehouses specifically designed for this type of data that should also be considered)

• Data alignment

  MongoDB makes a compromise between efficiency and consistency. The rule is to change one document: always , and updates for several documents should never be considered atomic. There is also no way to “block” a record on the server (you can build it in the client logic using, for example, the “block” field). When you design a chart, consider how you will keep your data consistent. Generally, the more you keep in the document, the better.

Pro tip

Even when you use links, it is often recommended to store some data from the link in the parent document. As a rule, I save enough information to build a meaningful link to the child in the parent.

In your example, this would mean storing the customer names along with the ObjectID in the reseller document so that I can create a link to each customer by name without a separate request. If creating a URL for a client requires something other than the identifier of its document, I would also save it.

Such tricks can reduce 1 + n request situations.

Answer 2

Does MongoDB save the "title" and "author" as text for each record of this object in this collection?

MongoDB is schematic, so the answer is obvious: yes, since there is no such scheme as a scheme

My second question: when should a "relationship" be? Let's say I have 100 resellers that contain (by objects) 1000 clients each, and each client has 10 projects. What makes for one huge common object to manipulate.

Please check

http://www.mongodb.org/display/DOCS/Schema+Design

Your options are embedded documents, database links, or multiple queries.