Database Reference
In-Depth Information
In this case, we might just revert to storing the
name
and
contact_id
redundantly in the row.
Of course, doing this results in the redundancy we were trying to get away from, and leads
to greater application complexity, as we have to make sure to update data in all its redundant
locations.
MongoDB: Who Needs Normalization, Anyway?
Into this mix steps MongoDB with the notion that your data doesn't always have to be tabular,
basically throwing most of traditional database normalization out, starting with first normal
form. In MongoDB, data is stored in
documents
. This means that where the first normal form
in relational databases required that each row-column intersection contain exactly
one
value,
MongoDB allows you to store an
array
of values if you so desire.
Fortunately for us as application designers, that opens up some new possibilities in schema
design.Because MongoDBcannatively encode suchmultivalued properties, wecangetmany
of the performance benefits of a denormalized form without the attendant difficulties in up-
dating redundant data. Unfortunately for us, it also complicates our schema design process.
There is no longer a “garden path” of normalized database design to go down, and the go-to
answer when faced with general schema design problems in MongoDB is “it depends.”
MongoDB Document Format
Before getting into detail about when and why to use MongoDB's array types, let's review
just what a MongoDB document is.
Documents
in MongoDB are modeled after the JSON
(JavaScript Object Notation) format, but are actually stored in BSON (Binary JSON). Briefly,
what this means is that a MongoDB document is a dictionary of key-value pairs, where the
value may be one of a number of types:
▪ Primitive JSON types (e.g., number, string, Boolean)
▪ Primitive BSON types (e.g., datetime, ObjectId, UUID, regex)
▪ Arrays of values
▪ Objects composed of key-value pairs
▪ Null
