Databases Reference
In-Depth Information
•
Your Coffee Shop Doesn't Use Two-Phase Commit
gives an example of how real-
world systems handle consistency and how that relates to database design.
Tip #2: Normalize if you need to future-proof data
Normalization “future-proofs” your data: you should be able to use normalized data
for different applications that will query the data in different ways in the future.
This assumes that you have some data set that application after application, for years
and years, will have to use. There are data sets like this, but most people's data is
constantly evolving, and old data is either updated or drops by the wayside. Most people
want their database performing as fast as possible on the queries they're doing now,
and if they change those queries in the future, they'll optimize their database for the
new queries.
Also, if an application is successful, its data set often becomes very application-specific.
That isn't to say it couldn't be used for more that one application; often you'll at least
want to do meta-analysis on it. But this is hardly the same as “future-proofing” it to
stand up to whatever queries people want to run in 10 years.
Tip #3: Try to fetch data in a single query
Throughout this section,
application unit
is used as a general term for
some application work. If you have a web or mobile application, you
can think of an application unit as a request to the backend. Some other
examples:
• For a desktop application, this might be a user interaction.
• For an analytics system, this might be one graph loaded.
It is basically a discrete unit of work that your application does that may
involve accessing the database.
MongoDB schemas should be designed to do query per application unit.
Example: a blog
If we were designing a blog application, a request for a blog post might be one appli-
cation unit. When we display a post, we want the content, tags, some information about
the author (although probably not her whole profile), and the post's comments. Thus,
we would embed all of this information in the post document and we could fetch ev-
erything needed for that view in one query.
