Relational or Non-relational? Start With the Access Task · Azure Data Fundamentals

Three questions before a product name

A defensible data-model decision starts with three questions:what facts must remain associated, how the application will retrieve or change them, and which changes must succeed together. A fourth operational question asks what the team wants the provider to manage. These questions are related, but no one label answers all of them. JSON can represent flexible documents; tables can represent entity relationships; an API defines client operations; and a transaction capability has a scope. A flexible representation does not eliminate a relationship or an atomicity requirement.

Relational systems organize entities in tables with declared columns and keys. A normalized design can reduce duplicated facts while preserving the links needed to retrieve them. A key/attribute or document model can provide different access structures. Do not derive an absolute product ranking from those descriptions. Also do not infer that all NoSQL systems lack transactions:the retained Cosmos DB for NoSQL evidence explicitly supports ACID operations within a logical partition. The useful decision names that boundary rather than replacing it with a category slogan.

Worked case: a travelling exhibition

Fictional case:an exhibition records venues, scheduled installations and a variable set of notes from each venue. Its coordinator must query which installations belong to each venue, update a venue’s current contact details, and retain the conditions agreed for each past installation. A separate mobile component retrieves a whole venue-note document through a stated native document API. Begin by writing each required fact and operation rather than choosing a service from the project’s cultural subject matter.

The venue-to-installation relationship can be represented with separate entity identities and references. A current contact attribute belongs with the venue, while an agreement snapshot belongs with the historical installation it describes. Their text values may coincide without being the same fact. Removing the historical snapshot in the name of eliminating duplication would violate the supplied retention requirement. For the mobile component, a nested document may preserve a varying collection of notes that is normally retrieved together. That representation choice does not prove that every cross-venue report or future client will use the same access pattern.

Now test a proposed atomic update to two mobile items. The team must state the API, logical partition relationship and supported operation before citing a guarantee. If the items are in one logical partition, the documented boundary may support the stated transactional mechanism. If a changed design puts them in different logical partitions, the same in-partition evidence does not establish an arbitrary cross-partition claim. Neither branch implies that the exhibition must convert every other table or document. Keep the conclusion local to the requirement.

Challenge the strongest alternative

A strong comparison considers what would make another design valid. Relational data can represent more than one entity through keys and joins; that is useful when the stated access requires those relationships. A document can group related information for a declared retrieval operation. Neither fact proves that the other model is incapable of storing any of the data. Ask whether the candidate meets the actual relationship, query and update conditions, then record what has not been assessed. Performance, cost, regional availability and operational compatibility require their own evidence.

The same discipline applies to schemas. A NULL in a declared column does not make a table schemaless. JSON is not automatically unstructured just because it is text. Nor does a document whose attributes vary automatically preserve every association when flattened into an export. Inspect the receiving contract. An array of paired objects, parallel arrays and a normalized child table can convey related facts through different shapes. Whether one is accepted depends on the required interface and how its relationships are interpreted.

A reusable decision record

For each candidate, write the required read/write task, the facts whose identity must be preserved, the grouping that must change atomically, and the client API expected to perform it. Then write a reason the closest alternative would fail an explicit condition—or admit that the current information does not establish a unique choice. A name such as managed, relational or NoSQL is not itself that reason. Separate supported facts from editorial design assumptions.

Use the two checks below to apply this record. The sequential lessons introduce representations, keys, storage models and the Cosmos boundary individually. This article combines them to resolve an access-task dispute. It is not a migration recipe and does not operate on a tenant or organizational database. A useful foundation answer can remain conditional while still explaining exactly which new fact would change the decision.