Why isn't SQL ANSI-92 standard better adopted over ANSI-89?

Question

At every company I have worked at, I have found that people are still writing their SQL queries in the ANSI-89 standard:

select a.id, b.id, b.address_1
from          


        

Answer 1

In response to the NATURAL JOIN and USING post above.

WHY would you ever see the need to use these - they weren't available in ANSI-89 and were added for ANSI-92 as what I can only see as a shortcut.

I would never leave a join to chance and would always specify the table/alias and id.

For me, the only way to go is ANSI-92. It is more verbose and the syntax isn't liked by ANSI-89 followers but it neatly separates your JOINS from your FILTERING.

Answer 2

Oracle does not implement ANSI-92 at all well. I've had several problems, not least because the data tables in Oracle Apps are so very well endowed with columns. If the number of columns in your joins exceeds about 1050 columns (which is very easy to do in Apps), then you will get this spurious error which makes absolutely no logical sense:

ORA-01445: cannot select ROWID from a join view without a key-preserved table.

Re-writing the query to use old style join syntax makes the issue disappear, which seems to point the finger of blame squarely at the implementation of ANSI-92 joins.

Until I encountered this problem, I was a steadfast promoter of ASNI-92, because of the benefits in reducing the chance of an accidental cross join, which is far too easy to do with old-style syntax.

Now, however, I find it much more difficult to insist on it. They point to Oracle's bad implementation and say "We'll do it our way, thanks."

Answer 3

I had a query that was originally written for SQL Server 6.5, which did not support the SQL 92 join syntax, i.e.

select foo.baz
from foo
  left outer join bar
  on foo.a = bar.a

was instead written as

select foo.baz
from foo, bar
where foo.a *= bar.a

The query had been around for a while, and the relevant data had accumulated to make the query run too slow, abut 90 seconds to complete. By the time this problem arose, we had upgraded to SQL Server 7.

After mucking about with indexes and other Easter-egging, I changed the join syntax to be SQL 92 compliant. The query time dropped to 3 seconds.

There's a good reason to switch.

Reposted from here.

Answer 4

A few reasons come to mind:

• people do it out of habit
• people are lazy and prefer the "old style" joins because they involve less typing
• beginners often have their problems wrapping their heads around the SQL-92 join syntax
• people don't switch to new syntax just because it is there
• people are unaware of the benefits the new (if you want to call it that) syntax has, primarily that it enables you to filter a table before you do an outer join, and not after it when all you have is the WHERE clause.

For my part, I do all my joins in the SQL-92 syntax, and I convert code where I can. It's the cleaner, more readable and powerful way to do it. But it's hard to convince someone to use the new style, when they think it hurts them in terms of more typing work while not changing the query result.

Answer 5

According to "SQL Performance Tuning" by Peter Gulutzan and Trudy Pelzer, of the six or eight RDBMS brands they tested, there was no difference in optimization or performance of SQL-89 versus SQL-92 style joins. One can assume that most RDBMS engines transform the syntax into an internal representation before optimizing or executing the query, so the human-readable syntax makes no difference.

I also try to evangelize the SQL-92 syntax. Sixteen years after it was approved, it's about time people start using it! And all brands of SQL database now support it, so there's no reason to continue to use the nonstandard (+) Oracle syntax or *= Microsoft/Sybase syntax.

As for why it's so hard to break the developer community of the SQL-89 habit, I can only assume that there's a large "base of the pyramid" of programmers who code by copy & paste, using ancient examples from books, magazine articles, or another code base, and these people don't learn new syntax abstractly. Some people pattern-match, and some people learn by rote.

I am gradually seeing people using SQL-92 syntax more frequently than I used to, though. I've been answering SQL questions online since 1994.

Answer 6

I can answer from the point of view of an average developer, knowing just enough SQL to understand both syntaxes, but still googling the exact syntax of insert each time I need it... :-P (I don't do SQL all day, just fixing some problems from time to time.)

Well, actually, I find the first form more intuitive, making no apparent hierarchy between the two tables. The fact I learned SQL with possibly old books, showing the first form, probably doesn't help... ;-)
And the first reference I find on a sql select search in Google (which returns mostly French answers for me...) first shows the older form (then explain the second one).

Just giving some hints on the "why" question... ^_^ I should read a good, modern book (DB agnostic) on the topic. If somebody has suggestions...