Introduction to MongoDB - MongoDB Basics - page 6

In this version of the example, each JSON object (or document) contains all the
information needed to understand it. If you look at phone_numbers , you can see that it
contains a list of different numbers. This list can be as large as you want. You could also
be more specific about the type of number being recorded, as in this example:
{
"firstname": "Peter",
"lastname": "Membrey",
"numbers": [
{
"phone": "[phone]"
},
{
"fax": "[phone]"
}
]
}
This version of the example improves on things a bit more. Now you can clearly
see what each number is for. JSON is extremely expressive, and, although it's quite easy
to write JSON by hand, it is usually generated automatically in software. For example,
Python includes a module called (somewhat predictably) json that takes existing Python
objects and automatically converts them to JSON. Because JSON is supported and used
on so many platforms, it is an ideal choice for exchanging data.
When you add items such as the list of phone numbers, you are actually creating
what is known as an embedded document . This happens whenever you add complex
content such as a list (or array , to use the term favored in JSON). Generally speaking,
there is also a logical distinction. For example, a Person document might have several
Address documents embedded inside it. Similarly, an Invoice document might have
numerous LineItem documents embedded inside it. Of course, the embedded Address
document could also have its own embedded document that contains phone numbers,
for example.
Whether you choose to embed a particular document is determined when you
decide how to store your information. This is usually referred to as schema design . It
might seem odd to refer to schema design when MongoDB is considered a schemaless
database. However, while MongoDB doesn't force you to create a schema or enforce one
that you create, you do still need to think about how your data fits together. We'll look at
this in more depth in Chapter 3.
Adopting a Nonrelational Approach
Improving performance with a relational database is usually straightforward: you buy
a bigger, faster server. And this works great until you reach the point where there isn't
a bigger server available to buy. At that point, the only option is to spread out to two
servers. This might sound easy, but it is a stumbling block for most databases. For
example, neither MySQL nor PostgresSQL can run a single database on two servers,
where both servers can both read and write data (often referred to as an active/active