Database Reference
In-Depth Information
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.
