Database Reference
In-Depth Information
What are your application access patterns?
In addition to understanding the basic
unit of data and the features of the database, you also need to pin down the
needs of your application. If you read the FriendFeed article just mentioned,
you'll see how the idiosyncrasies of an application can easily demand a schema
that goes against firmly held data modeling principles. The upshot is that you
must ask numerous questions about the application before you can determine
the ideal data model. What's the read/write ratio? What sorts of queries do you
need? How is the data updated? What concurrency issues can you expect? How
well structured is the data?
The best schema designs are always the product of deep knowledge of the database
you're using, good judgment about the requirements of the application at hand, and
plain old experience. The examples in this chapter, and the schema design patterns in
appendix B, have been designed to help you develop a good sense for schema design
in MongoDB. Having studied these examples, you'll be well prepared to design the
best schemas for your own applications.
4.2
Designing an e-commerce data model
Demonstrations of next-generation data stores typically revolve around social media:
Twitte r-like de mo apps are the norm. Unf ortunat ely, such apps tend to have rather
simple data models. That's why, in this and in subsequent chapters, we'll look at the
much richer domain of e-commerce. E-commerce has the advantage of including a
large number of familiar data modeling patterns. Plus, it's not hard to imagine how
products, categories, product reviews, and orders are typically modeled in an
RDBMS
.
This should make the upcoming examples more instructive, since you'll be able to
contrast them with some of your preconceived notions of schema design.
E-commerce has often been a domain exclusive to
RDBMS
s, and this is true for a
couple of reasons. The first is that e-commerce sites generally require transactions,
and transactions are an
RDBMS
staple. The second is that, until recently, domains that
require rich data models and sophisticated queries have been assumed to fit best
within the realm of the
RDBMS
. The following examples call into question this second
assumption.
Before we proceed, a note on scope is in order. Building an entire e-commerce
back end isn't practical within the space of this topic. What we'll do instead is pick out
a handful of e-commerce entities and show how they might be modeled in MongoDB.
In particular, we'll look at products and categories, users and orders, and product
reviews. For each entity, I'll show an example document. Then, we'll hint at some of
the database features that complement the document's structure.
For many developers,
data model
goes hand in hand with
object mapping
, and for that
purpose you've probably used an object-relational mapping library, such as Java's
Hibernate framework or Ruby's ActiveRecord. Such libraries are all but necessary for
building applications efficiently on an
RDBMS
. But they're less necessary with
MongoDB. This is due in part to the fact that a document is already an object-like
