Codd's non-subversion rule forbids any low-level interface that bypasses the integrity rules enforced by the higher-level relational language. Which of Codd's rules do mainstream SQL engines actually fail, and how much should that influence a database choice?
answer
- Rule 12: fast path must not be a correctness bypass
- loaders skipping constraints; NOT VALID constraints
- weakest: view updating, distribution independence, integrity independence
- strongest: catalog, SQL sublanguage, set ops, physical independence
- checklist for gaps, not a vendor scorecard
basics
~20 sNon-subversion means bulk loaders and record-level APIs must not skip constraints or authorisation. Mainstream engines commonly fall short on view updating, integrity independence, distribution independence and full non-subversion. It matters as a checklist of where your team must compensate, not as a product-selection score.
solid answer
~60 s**Non-subversion (Rule 12):** if the system offers a low-level or record-at-a-time interface, that interface must not be able to subvert the integrity constraints and authorisation rules expressed in the relational language. Practically: a bulk loader, a direct-path insert, or a replication apply path must not be a way to smuggle in rows that a normal insert would reject. Where engines fall short: - **Rule 6 (view updating):** only a simple subset is auto-updatable. - **Rule 10 (integrity independence):** constraints are declarable, but a great deal of business rule enforcement still lives in application code. - **Rule 11 (distribution independence):** sharding and read replicas are visible to applications through routing and staleness. - **Rule 12:** loaders that disable constraint checking, and triggers or foreign keys that are not applied on some replication paths. - **Rule 1/2 pragmatics:** SQL tables permit duplicates and keyless tables. As a selection criterion the rules are weak — nothing passes. As a design checklist they are useful: each gap names a place where your team, not the engine, will be enforcing correctness.
go deeper
Know that non-subversion means no interface may skip the constraints declared in the schema, and that a fast load path is the usual temptation.
Name two or three rules engines fail and give one concrete example each.
Talk through operational subversion paths — loaders, not-validated constraints, replication apply — and how you detect and close them.
Reject the scorecard framing, then convert specific gaps into team policy: key mandates, declared-versus-service invariants, documented routing and staleness, owners for every validation-skipping path.
## The non-subversion rule Codd's twelfth rule: *if the system provides a low-level (single-record-at-a-time) interface, that interface cannot be used to subvert or bypass the integrity rules and constraints expressed in the higher-level relational language.* The target was products offering a fast native API alongside SQL, where the fast path skipped constraint checking and authorisation. The rule says performance escape hatches must not be correctness escape hatches: if the schema declares a foreign key, every write path honours it, whatever interface it arrives through. Modern equivalents of the concern are everywhere: - **Bulk loaders and direct-path inserts** that can be told to skip constraint validation for throughput, leaving data the schema says is impossible. - **Constraints created as not-validated** to avoid a long scan, so existing rows were never checked. - **Replication apply paths** that do not fire triggers or re-check constraints on the replica, so a replica can diverge from what the schema claims. - **Superuser paths** that write catalogs or files directly. The practical rule of thumb: any switch that makes a write faster by not checking something is a Rule 12 issue, and its use has to be paired with a validation step and an explicit owner. ## Scoring mainstream engines No engine passes all thirteen rules. The honest scorecard looks roughly like this. **Well satisfied.** Rule 4 (active online catalog) — native catalogs plus INFORMATION_SCHEMA are excellent. Rule 5 (comprehensive data sublanguage) — SQL covers definition, manipulation, constraints, authorisation and transaction boundaries in one language. Rule 7 (high-level insert, update, delete) — set-at-a-time operations are the norm. Rule 8 (physical data independence) — strong; storage layout, indexes and partitioning change without rewriting queries. **Partly satisfied.** Rule 1 and 2 — SQL permits duplicate rows and keyless tables, so guaranteed access is a discipline you impose rather than a property you get. Rule 3 — one null marker, with the empty-string collapse on at least one major engine. Rule 9 (logical data independence) — views help but writes and structural change still ripple. Rule 10 (integrity independence) — declarative constraints exist and are underused; cross-row and cross-table rules frequently end up in application code where they are unenforced against other writers. **Weakly satisfied.** Rule 6 (view updating) — auto-updatable subset only. Rule 11 (distribution independence) — the moment a system shards or adds read replicas, applications learn about routing keys, cross-shard limits and replica staleness. Rule 12 — fast paths that skip checks exist and are used. ## How much should this drive a database choice? As a **selection score**, very little. Every candidate fails, the failures cluster in the same places, and the differences that decide real choices — operational maturity, replication and failover behaviour, ecosystem, cost, team familiarity, workload fit — are not on Codd's list at all. Treating rule counts as a ranking is a red flag. As a **design checklist**, it is genuinely useful, because each gap names work that transfers to your team: - Rule 2 gap → mandate primary keys on every table; keyless tables are unaddressable rows. - Rule 10 gap → decide deliberately which invariants are declared in the schema versus enforced by a service, and accept that anything not declared is unenforced against every other writer, including a console session. - Rule 11 gap → if you shard or read from replicas, the distribution is part of your application's contract; document routing keys and staleness expectations rather than pretending they are invisible. - Rule 12 gap → inventory every path that can skip validation — loaders, not-validated constraints, replication apply — and require a validation step and an owner for each. - Rule 6 gap → expect a view layer to insulate reads far better than writes. ## The framing that lands Codd's rules were an argument in a specific fight about what the word relational meant, and that fight is over. What survives is a way of naming exactly which correctness guarantee a system does not give you, so the gap becomes an owned decision instead of an assumption. A principal-level answer says the rules are not a scorecard, then converts two or three specific gaps into concrete policy for the team.
- Give a concrete modern example of a Rule 12 subversion and how you would control it.A bulk load run with constraint checking disabled, or a foreign key added as not-validated to avoid a long scan, both leave rows the schema claims are impossible. Control it by treating the skip as a temporary state with a mandatory follow-up validation step, restricting who can use the fast path, and alerting if a not-validated constraint persists past the load window.
- Which rule does adding read replicas most directly compromise, and what does that cost the application?Distribution independence. Once reads can be served from a replica, applications must reason about replication lag — read-your-own-writes breaks, and code must route consistency-sensitive reads to the primary or wait for a lag bound. The distribution stops being invisible and becomes part of the application contract.
saying these in an interview costs you the question
- Ranking databases by how many Codd rules they satisfy — all fail, and the differences that matter are elsewhere.
- Believing constraints are always enforced regardless of write path; loaders and not-validated constraints skip checks.
- Assuming sharding or read replicas are transparent to application code.
- Treating business rules enforced only in application code as equivalent to declared constraints — another writer bypasses them entirely.