1.4The diversity of data models and NoSQL

While the relational model is widely used in today's systems, large-scale web services and real-time analytics platforms sometimes run into the relational model's constraints (a strict schema, difficulty scaling horizontally), and various NoSQL styles have risen to address them. This section is not about memorizing each data model's features side by side; it centers on the judgment of which data model best fits a given requirement. The key perspective is that the relational model is not always optimal, nor is NoSQL always superior—it is a matter of choosing the right tool for the job.

1.4.1Traditional data models

• The hierarchical model represents data as a tree structure (parent-child relationships), where a child may have only one parent. The network model extends the hierarchical model into a network structure in which a child may have multiple parents. Both predate the relational model as the mainstream approach, and both carried the constraint that the data structure was strongly tied to the application's access path.
• The relational model, grounded in mathematical set theory, separates data structure from access path (achieving data independence). The object-oriented model treats a programming language's objects (classes, inheritance, encapsulation) directly as the database structure; it suits data with complex structure (CAD drawings, multimedia, etc.) but saw only limited adoption.

1.4.2The four NoSQL styles

• A key-value store (KVS) manages data as simple key-value pairs, making key-based lookups and updates extremely fast. Because the DBMS does not understand the value's internal structure, it suits simple access patterns like session data and caching. Document-oriented stores store data as semi-structured documents (e.g., JSON), where each document can have a flexible schema. This suits data like catalog information where the number of fields varies per record.
• Column-oriented storage groups data together by column, making reads fast for workloads that aggregate or analyze a specific column across a huge number of records (analytics platforms, time-series data). A graph database represents data and relationships directly as nodes (vertices) and edges, processing queries that traverse multi-hop relationships (an SNS friend graph, recommendations, fraud-detection link analysis) faster than the relational model's multi-way joins would.

Suppose you are the database designer tasked with designing a new SNS feature: "recommendations via friends-of-friends (2nd-degree connections)." The existing relational database has a junction table storing follow relationships between users, but trying to satisfy the requirement of "quickly traversing 2-3 hops of connections from user A to surface recommendation candidates" using relational SQL would require multiple levels of self-join, with the join cost growing exponentially as the number of hops increases. Concluding here that "the relational model has powerful SQL, so a cleverer join will solve it" and stopping at join optimization alone merely postpones a performance bottleneck at scale. For a requirement that frequently traverses multi-hop relationships, a graph database, which represents relationships directly as nodes and edges, is structurally better suited—a 2-3 hop search can be processed quickly as a graph traversal rather than a join. On the other hand, if the same SNS service also needs to "store user profile settings (a flexible structure whose number of fields is likely to grow or shrink over time)," a document-oriented database that does not rigidly fix the schema up front is the better fit. Not trying to cover every requirement with a single data model, but instead using the optimal model for each access pattern side by side (polyglot persistence), is an important mindset in large-scale system design.

1.4.3Section summary

• The hierarchical model (one child, one parent) and the network model (one child, multiple parents) are traditional models predating the relational model. The relational model separates data structure from access path, achieving data independence
• The four NoSQL styles (KVS/document-oriented/column-oriented/graph DB) each excel at a different access pattern, and the choice among them depends on the requirement's access pattern
• A graph database for requirements that traverse multi-hop relationships, document-oriented for a flexible schema—the mindset of combining multiple models side by side (polyglot persistence) matters in large-scale design