When Are Standards Restrictive

In our various confrontations regarding OO-versus-relational [links to follow], there seems to be key theme emerging. TopMind views relational as a set of standards that make dealing with "state systems" (structures) more consistent between shops and developers, and allowing better communications between applications and systems. However, some see it as limiting. Relational, and SQL in particular, are pretty high-level standards. Is there an upper limit to how high-level standard abstractions can get and still be net beneficial? Is it restricting to go above a certain point?

From ObjectOrientedDesignIsDifficult:

Perhaps because foolish consistency is the hobgoblin of small minds?

I note somebody inserted the word "foolish". Of course, measuring foolishness will probably lead to many a HolyWar.

The original from Ralph Waldo Emerson is exactly as quoted, including the word foolish.

If you want to get pedantic, the exact quote is "a foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines". It's both underappreciated and overused, and tends to be quite unproductive in debates.

Exactly!

Not to get involved in the OoVsRelational pissing-match, but there are many instances where the merits of a constrained system vs an unconstrained system are discussed. Examples:

OO-Vs-Relational (ObjectRelationalPsychologicalMismatch)
StaticTyping vs DynamicTyping
Languages with SideEffects vs those without
XmlIsaPoorCopyOfEssExpressions. While some of this argument centers on whether <foo> and </foo> is (or isn't) a better structure delimiter than ( and )--much of it centers on the suggestion that if EssExpressions are used to represent structured data (which does make sense), that hey!--LispLanguage can be used to express "schema", constraints, and other such stuff. XML advocates retort that the embedding of general-purpose programming languages as part of XML was avoided for a reason.
GangOfFour-style OOP patterns

If a system is constrained--it is easier for a tool (or other software) to reason about it, and do things like a) prove it correct, b) detect errors in advance of deployment, c) perform elegant and efficient transforms on the system, etc. For an unconstrained system, such reasoning may be difficult, computationally intractable, or even undecidable. On the other hand, unconstrained systems can be quite a bit friendlier to use--so much so that many developers here on Wiki prefer them.

I think it is a personal preference. If the constraints match the way one thinks, or perhaps matches their domain, then one is more likely to adopt, live with, and study such system. If not, then it feels artificially constraining. I like the rules/constraints of relational, but I don't like static typing. (There could be dynamic-relational I would note. See MultiParadigmDatabase).

Under PatternBacklash it was suggested that standards can simplify communication between techies by creating a common vocabulary or notation.

Standards are always restrictive. That's what they do. They're also unavoidable in just about every endeavor other than finger painting.

Consistency is the better option better if it has little or no extra cost.

Consistency is to be preferred over inconsistency if accuracy is more important than freedom to improvise. What follows is either order or chaos. Standards are designed to reduce chaos and increase order. Standards are innovation's BestPractices. --DonaldNoyes

See DatabaseVerbs, PrincipleOfLeastPower

CategoryOrganization