Databases Reference
In-Depth Information
CHAPTER 2
Options for Storing Connected Data
We live in a connected world. To thrive and progress, we need to understand and in‐
fluence the web of connections that surrounds us.
How do today's technologies deal with the challenge of connected data? In this chapter
we look at how relational databases and aggregate NOSQL stores manage graphs and
connected data, and compare their performance to that of a graph database. For readers
interested in exploring the topic of NOSQL,
Appendix A
describes the four major types
of NOSQL databases.
Relational Databases Lack Relationships
For several decades, developers have tried to accommodate connected, semi-structured
datasets inside relational databases. But whereas relational databases were initially de‐
signed to codify paper forms and tabular structures—something they do exceedingly
well—they struggle when attempting to model the ad hoc, exceptional relationships that
crop up in the real world. Ironically, relational databases deal poorly with relationships.
Relationships do exist in the vernacular of relational databases, but only as a means of
joining tables. In our discussion of connected data in the previous chapter, we men‐
tioned we often need to disambiguate the semantics of the relationships that connect
entities, as well as qualify their weight or strength. Relational relations do nothing of
the sort. Worse still, as outlier data multiplies, and the overall structure of the dataset
becomes more complex and less uniform, the relational model becomes burdened with
large join tables, sparsely populated rows, and lots of null-checking logic. The rise in
connectedness translates in the relational world into increased joins, which impede
performance and make it difficult for us to evolve an existing database in response to
changing business needs.
Figure 2-1
shows a relational schema for storing customer orders in a customer-centric,
transactional application.
