Database Reference
In-Depth Information
author: 'msmith',
vote_count: 20,
B
Tags stored as
array of strings
tags: ['databases', 'mongodb', 'indexing'],
image: {
url: 'http://example.com/db.jpg',
caption: '',
type: 'jpg',
size: 75381,
data: "Binary"
Attribute points to
another document
C
},
D
Comments stored as
array of comment objects
comments: [
{ user: 'bjones',
text: 'Interesting article!'
},
{ user: 'blogger',
text: 'Another related article is at http://example.com/db/db.txt'
}
]
}
Listing 1.1 shows a sample document representing an article on a social news site
(think Digg). As you can see, a document is essentially a set of property names and
their values. The values can be simple data types, such as strings, numbers, and dates.
But these values can also be arrays and even other documents
C
. These latter con-
structs permit documents to represent a variety of rich data structures. You'll see that
our sample document has a property,
tags
B
, which stores the article's tags in an
array. But even more interesting is the
comments
property
D
, which references an
array of comment documents.
Let's take a moment to contrast this with a standard relational database representa-
tion of the same data. Figure 1.1 shows a likely relational analogue. Since tables are
essentially flat, representing the various one-to-many relationships in your post is
going to require multiple tables. You start with a posts table containing the core infor-
mation for each post. Then you create three other tables, each of which includes a
field,
post_id
, referencing the original post. The technique of separating an object's
data into multiple tables likes this is known as
normalization
. A normalized data set,
among other things, ensures that each unit of data is represented in one place only.
But strict normalization isn't without its costs. Notably, some assembly is required.
To d i s p l a y t h e p o s t w e j u s t r e f e r e n c e d, y o u ' l l n e e d t o p e r f o rm a j o i n b e t w e e n t h e p o s t
and tags tables. You'll also need to query separately for the comments or possibly
include them in a join as well. Ultimately, the question of whether strict normalization
is required depends on the kind of data you're modeling, and I'll have much more to
say about the topic in chapter 4. What's important to note here is that a document-
oriented data model naturally represents data in an aggregate form, allowing you to
work with an object holistically: all the data representing a post, from comments to
tags, can be fitted into a single database object.
