Re: Is Oracle SQL99 Compliant?

I answered Mark's post in detail via email (which is what I saw first). To prevent the thread from exploding let me summarize: a) Any SQL reference out there details the SQL implemented by a product.

    The Oracle Ref also does not detail differences and limitations     against SQL-2003 (who would blame them?) b) FRED goes back to the early versions of DB2 (AFAIK) V2. With every

    release the incompatible differences dwindle as IBM adjusts its     products to the SQL standard (as I said: IBM didn't get born into     open standards - it's a lesson learned).     Fred did contain _commonalities_ and differences.
(similar in a way as the shared SQL Ref of XPS and IDS)
    So this is not anti-FRED. It is FRED for new releases for customers     wanting to write portable code (who don't want to read about the     stuff they shouldn't do). (It is not written for Oracle     marketing.. sorry Mark)
c) As you check out Mark's list you will find that there are few

    incompatibilities in DML statements which is what app developers are     concerned about. This is where the expense is when enabling an app.     The expense is not in DDL differences and pysical design.     When DML statements need to be written in a specific way to     exploit the physical design SQL has missed the boat. d) a typical example of DB2 cross-platform product development is

    the lack of "nested safepoint" support Mark pointed out for DB2     for LUW. Safepoints were
    introduces into DB2 V8 for LUW GA. Nested safepoints were introduced     in V8.2. In the next release of the reference the note quoted by Mark     will be gone.
    Some customers want to exploit the products, others want to write     portable code. Both have valid reasons. Different platforms have     different requirements. As LUW leads with BI features, zOS leads     with OLTP features. - and Oracle customers need a MODEL clause and     regular expression search - fine by me....     The trick is that the features are compatible once implemented.
(and on compatible legacy is chipped away at).

Just like IBM customers demand compatible features amongst DB2 products customers demand compatible features across vendors! IBM is adressing the problem in its own shop and it works solve the bigger problem.
Example: DB2 V7 introduced IDENTITY columns, generated columns and sequences. All these features were standardized as part of the process. But not by the original vendors, but lead by IBM working with those who cared.
Great care was taken to enable other vendors to become standard compliant with little effort.
That is the whole point of this thread.
Competition and innovation thrives on standards not on lock-in.

Both Oracle and MS SQL Server have implemented common table expressions (WITH). A feature that is part of the standard, delivered by IBM (and not fully implemented by IBM, Oracle leap-frogged DB2!). There was no need for either vendor to reverse-engineer behavior (and getting it wrong in the process). The definition is right in the standard document so SQL containing WITH can be ported with ease. When DB2 pulls even the language will (better) be the same.

In IBM we call this "cooperate on externals, compete on implementation". Works for wiper-blades, spark plugs, batteries, railways, poweroutlets, even hardware... why not for databases?

Ideally standardization happens before implementation. The other way is precedence setting. What happens in that case is that another group of folks has a different (maybe better, maybe not) view. Then there are two choices: Either the precedence is so strong that there is no choice (defacto-standard). Or other groups decide not to follow and the result is that the standard becomes irrelevant.

IMHO Oracle is playing the precedence game. Shoot first ask questions later. Customers suffer in this play because they either have to use a suboptimal solutions to a problem or they get locked in because a solution becomes non-portable.
The result in the later is that customers add abstraction layers and teh value of the DBMS get lost. It is exactly that what is currently happening when you look at the middle-ware space. Customers do select * and single row insert building and storing resultsets in beans and doing the work SQL was supposed to do close to the data in the client.

Cheers
Serge Received on Sat Jan 15 2005 - 11:51:56 CST