Basically were creating a oil refinery, I wouldn't expect that materials from different suppliers wouldn't adhere to released standards in subtle yet important ways. Pipework, valves along with other aspects of one supplier would include flanges and wall thicknesses to ANSI standards, as would exactly the same parts from the other supplier. Interoperability and system safety factors are therefore assured.

Why then would be the common databases so selective about which areas of the standards they stick to, and why don't have any 100% standards-compliant systems arrived at the forefront? Would be the standards 'broken', missing in scope or too hard to create for?

Using this to conclusion what's the reason for ANSI (or ISO) determining standards for SQL?

Edit: Listing of implementation variations between common databases

Most likely because standards conformance is of the low priority to database system customers. They care more about:

  • compatibility using what they have already got
  • performance
  • cost
  • OS support

to title but a couple of factors.

This is also true of programming languages - very couple of (if any) compilers support each and every feature from the current ANSI C and C++ standards.

Why make use of standard, well most suppliers do eventually bring standard support aboard. For instance, most suppliers support pretty much all SQL89. This enables the seller to tick a (relatively trivial) check-box on their own spec sheet as well as allow people much like me who are curious about writing portable code to do this, although needing to forgo plenty of features.

I'm not sure a brief history of ANSI SQL particularly. However it appears that lots of occasions in software development, standards are written following the major gamers have previously implemented their very own proprietary versions of things. When a clients are committed to its very own method of doing things, it is tough to justify altering or getting rid of features people have started to depend on just to stick to a typical. Web standards really are a primary illustration of this phenomenon.

Within the software industry you've some standards which are really standards, i.e., items that do not adhere to them just aren't effective. File specifications fall under that category. However you might also need "standards" which are a lot more like recommendations: they might understood to be standards with point-by-point definitions, but routinely implemented only partly or with significant variations. Web design is filled with such "standards", like HTML, CSS and "ECMAScript" where different suppliers (i.e. browsers) implement the standards in a different way.

The variation causes head aches, however the standardization still provides benefits. Let's suppose there have been no HTML standard whatsoever and every browser used its very own markup language. Likewise, let's suppose there have been no SQL standard and every database vendor used its very own completely proprietary querying language. There'd considerably more vendor lock-in, and designers would have a harder time working using more than one product.

So, no, ANSI SQL does not serve exactly the same purpose as ANSI standards do in other industries. However it does serve a helpful purpose nevertheless.

Indeed, the ANSI SQL standard isn't frequently adopted. Just read SO: most SQL threads never make reference to the conventional while, for example, discussions on network methods frequently range from the actual quote, chapter and verse from the relevant RFC.

I usually suspected that certain from the reasons is always that the SQL standard isn't freely distributable. Simply setting it up isn't trivial. Various unofficial copies float around.)

One more reason is that it's a very complicated text and poorly organized. It utilizes a strange vocabulary (for example "authID" rather "user"). You'll need books simply to comprehend the standard ("Helpful tips for the SQL standard", C.J. Date, Hugh Darwen - Addison-Wesley).

Begin to see the article "IS SQL A Genuine STANDARD Any longer?" for any discussion concerning the current (2005) issues from the SQL standard.