How different are the top DB vendor's SQL (DML-) dialects from each other?

Question

Does someone who has worked extensibly SQL-wise with at least two top DB products (such as Oracle, SQL Server, Informix, Sybase, DB2, Teradata) know how different the DB vendor's SQL dialects are from each other. Since I come from an Oracle background, I am especially interested in

• analytical functions
• model clauses
• hierachical queries (start with .. connect by comes to mind)
• any other feature that is more than the usual (select x, y from a, b where...)

Probably, the question boils down to if and to what extent these features are regulated by an ansi standard.

Practically, I'd like to know if there are "rule of thumbs" that would indicate if (and how) I can take an SQL DML-statement that runs on one database and let it run on an other database.

Answer 1

ANSI is a private non-profit organization that creates voluntary standards. As such it doesn’t actually regulate anything. Often it is to a company’s benefit to follow recognized standards, which is why many database companies follow the ANSI standard for SQL. Of course as each company seeks to differentiate their products, they will develop additional functionality beyond the standards.

From w3schools:

Although SQL is an ANSI (American National Standards Institute) standard, there are many different versions of the SQL language.

However, to be compliant with the ANSI standard, they all support at least the major commands (such as SELECT, UPDATE, DELETE, INSERT, WHERE) in a similar manner.

Note: Most of the SQL database programs also have their own proprietary extensions in addition to the SQL standard!

The differences between the SQL dialects is too great in the more specialized areas you listed to simplify the problem down to a “rule of thumb”. In these situations you probably should convert the entire statement for each database. By doing this each statement can be optimized for each platform taking advantage of the special features each database can provide. Writing SQL to lowest common denominator (ANSI) may simplify migration, but at the cost of performance.

SQL Dialects Reference gives some useful comparisons of the SQL variants. For more information I recommend searching for the specific dialects you are switching between like this:

   differences between mysql and oracle sql

Answer 2

At one time or another I've worked with all of the databases you mention. Unfortunately I have found that it doesn't take very long at all for the syntax to deviate in to their own flavours, for anything other than the simplest SELECT, INSERT, UPDATE and DELETE. When it gets to some of the categories you suggest it will quickly get vendor specific. I've always pretty much had to 'port' my SQL from one platform to another. Although going back a few years I was amazed at how different SQL Server and Teradata SQL was for even an UPDATE with a a few joins in it was.

Answer 3

Each vendor generally conforms to a minimum core of standard syntax. SQL-92 is generally the standard most conform to. They then add additional functionality on top of that. SQL3 adds procedural functionality to the syntax standard. Conformance to this standard is a lot lower. Vendors often will make claims to certain conformity. Conforming to the standard only means that they supply "at least" this functionality. They can supply any amount of functionality and therefore syntax beyond that standard. Each database vendor than also adds functionality that is specific to the way that they implement their database structure. This is how each database vendor attempts to provide an edge over their competition. Minor or no syntax difference are common for more universal functionality but since a lot of people make the decision about their database vendor based on the additional functionality that they provide or support this can be the key functionality that is vastly different or non existent between vendors.

Answer 4

Just tossing it out there for discussion, even tho it could've likely been a comment as well. This is why most people like using the various frameworks nowadays like EntityFramework and LINQ, where all the underlying abstraction of querying is relegated to the application layer, and the datalayer is just flat storage.

Note that this gives another benefit to the NoSQL crowd, as the database is just a storage medium.

Answer 5

Some database vendors provide detailed information about their ANSI SQL standard compliance. For Teradata, they specifically list SQL standards for each element of the ANSI standard, and for each detailed item -- like for each function, data type, etc. I have not seen general assertions about Teradata compliance, but I did search two documents for "SQL:2", which would get any recent ANSI compliance. They are ANSI SQL:2011 compliant for everthing but triggers, stored procedures, and hex literals, which are compliant with SQL:2008.

The devil is in the details, and you must have them to determine how if a database is ANSI SQL compliant at any level. Also it's not enough to fit the old standard of SQL-92 (aka SQL2). If a vendor provides good support for a newer standard, doesn't that say a lot about database quality?

A good place for information to compare database is "SQL In a Nutshell", 2nd or 3rd edition, by Kline, Kline and Hunt, and published by O'Reilly. They have several tables that compare different database features to SQL:2003. Teradata is not in the list, but since they are at least SQL:2003 compliant, I can use the list to compare database features.

Looking at the lists in the O'Reilly book, I can find features in Oracle that do not support the SQL:2003 standard. Of course, I need to check to Oracle documentation to verify those facts, since that book is dated. Then the Oracle to SQL:2003 comparison will help me in my big conversion project from Oracle to Teradata.