Why does no database fully support ANSI or ISO SQL standards?

Question

If I were designing a oil refinery, I wouldn\'t expect that materials from different vendors would not comply with published standards in subtle yet important ways. Pipework, v

Answer 1

Most of them are pretty compliant. But here's the bad news, IMO - standards breed mediocrity. Vendors want you to get locked into their extensions, and there's often good reason to do to nonstandard things. Realistically, how likely are you to dump Oracle for SQL Server, or vice-versa? Unless you build a product that your cusotmers may use against other databases, you as an enterprise are unlikely to swap out DB's. Too painful.

Answer 2

Probably because standards conformance is of a low priority to database system purchasers. They are more interested in:

• compatibility with what they've already got
• performance
• price
• OS support

to name but a few factors.

The same is true of programming languages - very few (if any) compilers support every single feature of the current ANSI C and C++ standards.

As to why bother with standard, well most vendors do eventually bring standard support on board. For example, most vendors support more or less all of SQL89. This allows the vendor to tick a (relatively unimportant) check-box on their spec sheet and also allow people like me who are interested in writing portable code to do so, albeit having to forgo lots of bells and whistles.

Answer 3

IMHO, the DB vendors push forward the ANSI SQL standards to include new features & constructs within their field much more than ANSI telling the DB vendors the "one true way".

The DB market is driven by features, scalability and cost. It is not a commercial priority to forego and delay a technical advantage (i.e. partitioning, pivot, UPSERT, replication) by waiting for ANSI to ratify the syntax. By the time that has been done, there is already a significant installation of the proprietary syntax.

That being said, most DB vendors have improved their core "ANSI SQL" support greatly in the last few years. (SQL Server with the SELECT FROM INFORMATION_SCHEMA and Oracle's ANSI joins actually working as well as native joins under the CBO)

Answer 4

The real reason: most "developers" are client-centric coders, and therefore neither understand nor care about Dr. Codd's 12 rules. This is also why MySql, which isn't a relational database in any significant manner, is frequently seen in webKiddie development. Such developers only want rudimentary SELECT, UPDATE, DELETE parsing. They eschew constraints of any kind, preferring to "do it in the application". Reactionary 1960's applications are what you get.

Answer 5

Companies usually tend to use one vendor to avoid having a jungle of different and possibly incompatible systems to support. It's also a lot cheaper to train your developers/system engineers in using one database vendor's tools than in 3 different sets of tools. Later on, this company may then grow large enough to buy some of its competitors. This would mean another entirely different set of tools that you'd have to manage, integrate, etc.

That's a lot of work.

Imagine that instead of that, you have a portability layer so that you really don't care what's beneath. That would be a lot better.

Answer 6

Mimer SQL has great standards support, yet it is pretty unknown. It is in production in several large sites, mostly in Sweden. But I think a lot of sites are migrating to others.

Detailed support statments:

• SQL-99
• SQL-2003
• PSM
• Database triggers and functions according to SQL:1999
• Binary and Character Large OBjects (BLOB/CLOB/NCLOB) support according to SQL:1999
• Multi-database transactions (two-phase commit) conforming to Open Group's XA-standard
• Support for Java ME CDC Foundation Profile and Java ME CLDC/MIDP