A Dovetail for a Packing Crate: When Simple Beats Clever

Opening Scene

A shipping crate needs to survive one truck ride and get discarded. A joiner who hand-cuts dovetails into its corners — the same painstaking joint reserved for a fine drawer meant to last generations — hasn’t demonstrated skill. They’ve wasted it. The crate needed nails and butt joints, assembled in minutes, strong enough for its one real job and no more. Every hour spent dovetailing a disposable box is an hour not spent on the piece that actually deserved that care, and worse, the over-built crate is often harder to open, harder to modify, and no more useful for its actual purpose than the simple version would have been.

Data models suffer from exactly this failure just as often as they suffer from under-engineering.

In Plain English

Over-engineering an ER pattern means applying a more elaborate structure than the business relationship genuinely requires — building a full supertype/subtype hierarchy for a distinction that will never grow past two fixed values, adding effective-dating to an attribute nobody will ever need historical answers about, or introducing a role-playing party model for entities that are permanently, genuinely distinct and will never overlap. The elaborate pattern isn’t wrong in the abstract; it’s wrong for this specific case, because it adds real query complexity, real maintenance burden, and real onboarding cost for flexibility the business will never actually use.

The Old Way

Over-engineering has typically crept in through a few recurring habits, long before AI made schema drafting faster:

• “We might need it someday” reasoning led modelers to build in flexibility for hypothetical future requirements that frequently never materialized, leaving behind permanent complexity paid for by every developer and query author from that point forward, in exchange for optionality that was never exercised.
• Pattern enthusiasm — having just learned a sophisticated technique — led to it being applied everywhere, including plenty of places a simple column or a plain foreign key would have served just as well, a version of reaching for the most impressive tool rather than the right-sized one.
• The cost of over-engineering was often invisible at first, showing up gradually as slower onboarding, more confusing queries, and a schema that intimidated rather than clarified — a genuine cost, just a quieter and more diffuse one than the cost of under-engineering.

Recognizing over-engineering has always required the willingness to ask “does this genuinely need to be this elaborate” even after the elaborate version is already built and working.

What’s Changing (and Why AI Is the Reason)

1. Generative AI schema-drafting tools, when given a rich or exhaustively detailed requirements prompt, can enthusiastically apply sophisticated patterns to relationships that don’t actually need them, since the AI has no inherent sense of which flexibility is genuinely likely to be used versus merely theoretically possible — that judgment still has to come from the person directing it.
2. AI-assisted “best practices” schema linting can flag the absence of patterns like effective-dating or supertype/subtype as if they were universally desirable improvements, when in a specific case the simpler existing structure was actually the correct, deliberate choice — treating every linting suggestion as automatically correct is itself a form of over-engineering by proxy.
3. AI agents and AI-generated documentation increasingly need to explain a schema’s design to new team members or other agents, and an over-engineered schema is measurably harder for an AI to summarize accurately and completely, exactly as it’s harder for a new human hire — added structural complexity has a real, compounding comprehension cost for every future reader, human or AI.

The Metaphor, Fully Extended

Joinery Element	ER Modelling Concept
A hand-cut dovetail joint, appropriate for a fine, lasting piece	A sophisticated pattern like supertype/subtype or effective-dating, appropriate when genuinely warranted
That same dovetail cut into a disposable shipping crate	That same pattern applied to a relationship that will never need its extra flexibility
The hours spent dovetailing the crate, unavailable for the piece that deserved them	The real query and maintenance complexity an unnecessary pattern imposes on every future developer
A simple nailed butt joint, exactly strong enough for the crate’s one real job	A plain column or straightforward foreign key, exactly sufficient for a relationship’s real requirements
A joiner asking “what does this piece actually need to survive its actual use” before choosing a joint	A modeler asking “does this relationship genuinely need this much structure” before applying a pattern

Quick Recap

• Over-engineering means applying a more elaborate ER pattern than a relationship genuinely requires, the same waste as hand-dovetailing a disposable shipping crate.
• “We might need it someday” is a common but weak justification for adding structural complexity that a real current requirement doesn’t yet demand.
• AI schema-drafting and linting tools can both nudge toward unnecessary sophistication unless explicitly directed by deliberate human judgment.
• Unnecessary complexity carries a real, ongoing comprehension cost for every future reader of the schema, human or AI.

Where This Fits in the Series

Article 10 covered recognizing which pattern fits; this article covered the specific risk of choosing one more elaborate than needed. Article 12 turns to how a team keeps its chosen patterns consistent and legible over time — the pattern catalog.