The Schema-Free Ideal and Branded Types | Databases

The NoSQL schema-free ideal

The “schema-free” ideal of NoSQL is sometimes described as a grail: a database that imposes no structural constraints on the data it stores. In practice, “no schema” really means:

The schema is not stored as part of the database, nor checked during update.

For most activities, there will inevitably still be a schema — perhaps on a whiteboard, a scrap of paper, or stored in somebody’s head. New joiners to a software project must learn this schema somehow; the DBMS provides no assistance.

The cost of schema absence

Aspect	With schema (RDBMS)	Without schema (NoSQL)
Discovery	`DESCRIBE TABLE`; system catalogues	Read the code; ask a colleague
Enforcement	DBMS rejects invalid writes	Invalid writes succeed silently
Tooling	Schema-aware editors, ORMs, code generation	Manual, ad-hoc
Evolution	Formal migrations (`ALTER TABLE`)	Application-level versioning of documents

Dynamic typing and its trajectory

The commercial success of dynamically-typed languages (JavaScript, Ruby, Python, PHP) is notable, but the trend is changing:

JavaScript is increasingly a compilation target, being displaced by WebAssembly (WASM).
Python types are now used de rigueur, pioneered by J. Lehtosalo (of this department) with mypy.
TypeScript has become the dominant way to write JavaScript at scale.
The industry is moving toward gradual typing: add types where they help, leave them out where they do not.

Branded types

Branded types represent the opposite end of the spectrum from semi-structured data. Databases hold many strings and numbers, many of which are members of enumerations or have units of measure (UoM). Should we make these types overt?

type velocity_t = branded float
type distance_t = branded float
type duration_t = branded int

Without branded types:

journey_time: int = 45        # minutes
bognor_to_romsey: int = 62    # miles
result = journey_time + bognor_to_romsey  # = 107 — dimensionally unsound!

The type system would not catch this error. With branded types:

journey_time: duration_t = 45
bognor_to_romsey: distance_t = 62
result = journey_time + bognor_to_romsey  # Type error!

Branded types prevent silly operations on data by tracking the semantic category of each value through the type system.

Being a key is a sort of type

When a value serves as the key to another table, that relationship itself is a form of typing. A person_id is not just any string — it is a string that must correspond to an entry in the People collection. This is referential integrity, and it is a type constraint that the DBMS could enforce (as RDBMSs do) or leave to the application (as document databases do).

Summary of the NoSQL / semi-structured area

Theme	Observation
Standards churn	RDF, OWL, YAML, SOAP, XMLRPC, JSON — many competing standards over two decades
Data size inflation	Human-readable representations have led to an order-of-magnitude increase in data size and parsing overhead compared with binary data exchange
Convergence	Many traditional SQL systems were extended with NoSQL features (JSON columns, document storage); many NoSQL systems added SQL-like query languages and transactions
Tripos note	For document database questions, a well-argued answer can garner full credit even if it disagrees with the expected answer

Summary

“Schema-free” means the schema is not stored in or enforced by the DBMS — not that no schema exists.
New joiners must learn the schema from documentation, code, or colleagues.
The industry is trending toward gradual typing and away from pure dynamic typing.
Branded types encode semantic categories (enumerations, units of measure) into the type system to prevent dimensionally unsound operations.
Relational and document approaches are converging, not diverging.