Which model, according to the picture, best fits the atomic change of an order with positions?

The relational model: Transactions change order and positions together. A document goes, but fits less well.

The product search should tolerate typos. Is the relational database still sufficient?

For simple full text search often yes, for example with PostgreSQL. A search index is worthwhile for typo tolerance and facets; weigh the additional operation against the benefit, the orders remain relational.

The team wants to move orders to a document database because it is modern. How do you rate that?

Modernity is not an access argument. Advantage: flexible structure. Disadvantage: Migration, new operating load and invariants that can be distributed across documents. Recommendation: Stay relational until a busy access speaks against it.

Decision spaceChapter II · Data · Building block 2 of 9

SQL & NoSQL

SQL and NoSQL systems offer different data models and promises. The selection follows accesses, consistency requirements and operating conditions.

By Michael Meierhoff · Meierhoff Systems

Access patternHow it is read and written.
Data modelHow a memory orders data.
Normal flowRelational first, NoSQL with reason.

Context

Why this is important

The memory model follows access, not habit. Relational is the normal case: tables, relationships and transactions cover many requirements. NoSQL, read as “Not only SQL”, needs a proven reason, such as access, which the relational model poorly serves. Combining multiple memories is Polyglot Persistence.

This building block explains the choice of a memory model. For the conscious use of several models see Polyglot Persistence.

At a glance · Access determines the data model

Access patterns and consistency needs show which data model fits.

Shop example · Model for access

Which data model fits this access?

Orders require nuclear status and position changes. Product search requires flexible full text queries across descriptions and categories.

This is how you read the picture

Access pattern The four accesses between which you choose above.
Data model The five cards, each with fits well, goes or fits badly.
Normal flow When ordering, only the relational model fits well.

RelationalTables, relationships, transactions
fits well · Best choice
Transactions change order and positions together or not at all.
DocumentationNested documents, flexible structure
goes
The order fits as a document; cross references to other data are heavier.
Key valueAccess directly from a key
fits badly
The value is opaque; checking or changing positions individually is cumbersome.
Column orientedColumn-by-column storage for evaluation
fits badly
Designed for large reads, not many small changes.
GraphNodes and Relationships at the Center
fits badly
Relationships are not the core here; an order is a simple structure.

Graph matches relationship queries like referral networks, which the shop does not have today.

Select an access; each card shows how well the model fits (accesses) 2 and 4 They are illustrative.

Benefits & limitations

Helps if:

Known access patterns and transaction needs lead to a data model that supports queries and invariants.
Differences in query forms, growth and consistency can be objectively compared based on the requirements.
A team with reliable backup, restoration and monitoring can operate an additional type of storage responsibly.

Boundaries

Choosing by trend rather than access patterns creates costly detours; test representative queries and data volumes before committing.
A poorly structured document model can separate invariants that belong together. Check transaction guarantees; see Transaction Boundaries.
Every additional storage technology requires operational work: backups, recovery and team knowledge.

In practice

Capture query forms, writing patterns, invariants, and growth assumptions. So you compare storage technologies based on actual accesses and requirements.
Check transaction guarantees and recovery path with representative data. A model choice is only viable if operation and migration are also covered.
Measure queries and fallback behaviour under expected load. Transaction Boundaries explores atomicity; Polyglot Persistence covers multiple stores.

Read the detailed explanation

Storage technologies differ in data models, transaction capabilities, query forms and operational requirements. Relational, document, key-value, column-oriented and graph models suit different access patterns. Their suitability depends on those patterns, invariants and operational goals.

Choose based on required reads and writes, invariants, scale and recovery goals. Several stores can work together when the authoritative source and derivation of read views are clear. Backups, monitoring and team expertise belong in the decision.

Transaction Boundaries defines which changes a store must protect together; Polyglot Persistence describes the additional costs of multiple storage models.

A store may support more than expected: PostgreSQL offers documents through JSONB and built-in full-text search. One store is often sufficient before Polyglot Persistence becomes necessary. NoSQL does not mean 'without transactions'; many document databases also support them.

Check your understanding

Test yourself in three stages

ReadingCheck in the picture
Which model, according to the picture, best fits the atomic change of an order with positions?
View the solution with justification
The relational model: Transactions change order and positions together. A document goes, but fits less well.
ApplyingTransferred to a new situation
The product search should tolerate typos. Is the relational database still sufficient?
View the solution with justification
For simple full text search often yes, for example with PostgreSQL. A search index is worthwhile for typo tolerance and facets; weigh the additional operation against the benefit, the orders remain relational.
EvaluateWeighing an alternative
The team wants to move orders to a document database because it is modern. How do you rate that?
View the solution with justification
Modernity is not an access argument. Advantage: flexible structure. Disadvantage: Migration, new operating load and invariants that can be distributed across documents. Recommendation: Stay relational until a busy access speaks against it.

Explore further

These building blocks continue the thoughts of this page.

References

Continue on the learning path

Next in Data & state: Transaction boundaries.

9 Building blocks

Continue withTransaction boundaries