Introduction to MongoDB - The Definitive Guide to MongoDB - page 8

Fitting Everything Together
Before we look at MongoDB's feature list, we need to review a few basic terms. MongoDB doesn't require much in the
way of specialized knowledge to get started, and many of the terms specific to MongoDB can be loosely translated to
RDBMS equivalents that you are probably already familiar with. Don't worry, though; we'll explain each term fully.
Even if you're not familiar with standard database terminology, you will still be able to follow along easily.
Generating or Creating a Key
A document represents the unit of storage in MongoDB. In an RDBMS, this would be called a row. However,
documents are much more than rows because they can store complex information such as lists, dictionaries, and even
lists of dictionaries. In contrast to a traditional database where a row is fixed, a document in MongoDB can be made
up of any number of keys and values (you'll learn more about this in the next section). Ultimately, a key is nothing
more than a label; it is roughly equivalent to the name you might give to a column in an RDBMS. You use a key to
reference pieces of data inside your document.
In a relational database, there should always be some way to uniquely identify a given record; otherwise it
becomes impossible to refer to a specific row. To that end, you are supposed to include a field that holds a unique value
(called a primary key ) or a collection of fields that can uniquely identify the given row (called a compound primary key ).
MongoDB requires that each document have a unique identifier for much the same reason; in MongoDB,
this identifier is called _id . Unless you specify a value for this field, MongoDB will generate a unique value for you.
Even in the well-established world of RDBMS databases, opinion is divided as to whether you should use a unique
key provided by the database or generate a unique key yourself. Recently, it has become more popular to allow the
database to create the key for you.
The reason for this is that human-created unique numbers such as car registration numbers have a nasty
habit of changing. For example, in 2001, the United Kingdom implemented a new number plate scheme that was
completely different from the previous system. It happens that MongoDB can cope with this type of change perfectly
well; however, chances are that you would need to do some careful thinking if you used the registration plate as your
primary key. A similar scenario may have occurred when the ISBN (International Standard Book Number) scheme
was upgraded from 10 digits to 13.
Previously, most developers who used MongoDB seemed to prefer creating their own unique keys, taking it
upon themselves to ensure that the number would remain unique. Today, though, general consensus seems to point
at using the default ID value that MongoDB creates for you. However, as is the case when working with RDBMS
databases, the approach you choose mostly comes down to personal preference. We prefer to use a database-provided
value because it means we can be sure the key is unique and independent of anything else. Others, as noted, prefer to
provide their own keys.
Ultimately, you must decide what works best for you. If you are confident that your key is unique (and likely to
remain unchanged), then you should probably feel free to use it. If you're unsure about your key's uniqueness or you
don't want to worry about it, then you can simply use the default key provided by MongoDB.
Using Keys and Values
Documents are made up of keys and values. Let's take another look at the example discussed previously in this chapter:
{
"firstname": "Peter",
"lastname": "Membrey",
"phone_numbers": [
"[phone]",
"[phone]"
]
}