Advanced: Data Models and Query Languages

Data models are layers of abstraction. Application objects become JSON, rows, graph vertices, indexes, files, pages, and finally bytes. Each layer hides lower-level complexity while imposing its own constraints.

Relational Model

The relational model represents data as relations, usually tables. It is strong when the data has regular structure, when joins are important, and when query flexibility matters.

Its main strengths are:

• declarative querying with SQL
• independence between logical queries and physical storage
• mature indexing and optimization
• strong support for joins and constraints

Its friction points appear when application data is deeply nested, highly heterogeneous, or better represented as a graph of relationships.

Document Model

Document databases group related data into self-contained documents. They fit cases where an aggregate is usually loaded and updated as a unit, such as profiles, catalog items, or event payloads.

The tradeoff is locality versus query flexibility. A document can reduce joins and match application shape well, but cross-document relationships and many-to-many references can become awkward.

Graph Model

Graph models emphasize relationships. They are strong when the important questions traverse connections: social networks, recommendation systems, access-control relationships, fraud graphs, knowledge graphs, and dependency graphs.

The model works best when relationships are numerous, heterogeneous, and evolving. It avoids forcing all relationships through rigid schemas or nested documents.

Declarative vs Imperative Querying

Declarative languages describe what result is wanted; the engine decides how to get it. Imperative code describes the steps. Declarative queries let databases optimize execution, parallelize work, and hide physical layout.

This is why SQL, Datalog-like languages, and graph query languages matter: they separate intent from execution strategy.

Practical Takeaway

Choose a data model based on access patterns and change patterns:

• Use relational models when joins, constraints, and ad hoc querying matter.
• Use document models when data is naturally aggregate-shaped.
• Use graph models when relationships are the center of the problem.
• Expect hybrid systems: many real applications use more than one model.