| Subject | OT:Bye-bye SQL? (opinion) |
|---|---|
| Author | Marius Popa Adrian |
| Post date | 2003-05-20T12:28:50Z |
http://www.silicon.com/opinion/500011-500001/1/4214.html
Although it may seem a no-brainer today, SQL took some time to get established with by no means all vendors subscribing to the notion of a common database query language. That, remember, is what SQL was originally designed to do - provide set-based query processing - the fact that it was soon appreciated that it could be used for other purposes, such as writing stored procedures, was a bonus.
However, by the early 1990s SQL was pretty much adopted by everyone (or, at least, the relational vendors - there were still plenty of pre-relational databases going strong) but there were lots of proprietary extensions to SQL. However, by the middle of the decade there was a real sense that new versions of the ANSI standard would subsume most of the differences between the different versions, and we would actually get a genuine SQL standard that was widely deployed and only minimally extended.
And then Informix bought Illustra and declared that it was introducing the Universal Database that would store everything. One consequence of that announcement was that companies like Oracle and IBM introduced extensive object capabilities into their databases. As a result they extended the SQL they used, in order to support the new capabilities of the database.
To cut a long story short, then came the internet and OLAP, followed by XML and, more recently, data mining and ETL, all embedded within the database. Now, leaving aside any questions of whether it is sensible to manage all of these diverse things from one place, these all involved further extensions to SQL.
For example, IBM has introduced more than 100 extensions to SQL just to support XML. And it is not limited to generic sets of extensions. There are also vendors including SQL extensions for specialised functions that SQL can't handle, such as time-lapsed queries (try asking a question such as "Who bought a barbecue within seven days of purchasing patio furniture?").
The question is: If companies are introducing hundreds of proprietary extensions to SQL has it actually gone so far away from the standard that to talk about it as if it were a common language is absurd?
The short answer to this question will depend on how you look at it. For all practical purposes, we should now be thinking about SQL as a language with a standard kernel and potentially unlimited extensions. However, the market has a vested interest in making us believe that SQL still remains a truly portable language. It is not or, at least, only at the kernel level.
There are some signs that suppliers are moving away from SQL. In particular, it is no longer the only language you can use for writing stored procedures. Vendors like Oracle and FirstSQL allow you to use Java as an alternative.
But there is no such movement away from using SQL for query processing. Yet the language is clearly inadequate, not only because of the extent of the dialects that are supported but also in the way that it allows the execution of very poorly formed code (which is why database optimisers have SQL rewrite capability).
Arguably this is a good thing - it allows novice programmers to still create useful queries - but it leads to bad habits and can hardly be considered a sound premise.
The fact is that we won't be saying goodbye to SQL any time soon but it is surely becoming over-bloated and it is not the panacea that the marketing departments of some suppliers would have us believe. Companies making buying decisions need to recognise that large numbers of SQL extensions make SQL a lock-in just as much as proprietary operating systems or hardware.
Although it may seem a no-brainer today, SQL took some time to get established with by no means all vendors subscribing to the notion of a common database query language. That, remember, is what SQL was originally designed to do - provide set-based query processing - the fact that it was soon appreciated that it could be used for other purposes, such as writing stored procedures, was a bonus.
However, by the early 1990s SQL was pretty much adopted by everyone (or, at least, the relational vendors - there were still plenty of pre-relational databases going strong) but there were lots of proprietary extensions to SQL. However, by the middle of the decade there was a real sense that new versions of the ANSI standard would subsume most of the differences between the different versions, and we would actually get a genuine SQL standard that was widely deployed and only minimally extended.
And then Informix bought Illustra and declared that it was introducing the Universal Database that would store everything. One consequence of that announcement was that companies like Oracle and IBM introduced extensive object capabilities into their databases. As a result they extended the SQL they used, in order to support the new capabilities of the database.
To cut a long story short, then came the internet and OLAP, followed by XML and, more recently, data mining and ETL, all embedded within the database. Now, leaving aside any questions of whether it is sensible to manage all of these diverse things from one place, these all involved further extensions to SQL.
For example, IBM has introduced more than 100 extensions to SQL just to support XML. And it is not limited to generic sets of extensions. There are also vendors including SQL extensions for specialised functions that SQL can't handle, such as time-lapsed queries (try asking a question such as "Who bought a barbecue within seven days of purchasing patio furniture?").
The question is: If companies are introducing hundreds of proprietary extensions to SQL has it actually gone so far away from the standard that to talk about it as if it were a common language is absurd?
The short answer to this question will depend on how you look at it. For all practical purposes, we should now be thinking about SQL as a language with a standard kernel and potentially unlimited extensions. However, the market has a vested interest in making us believe that SQL still remains a truly portable language. It is not or, at least, only at the kernel level.
There are some signs that suppliers are moving away from SQL. In particular, it is no longer the only language you can use for writing stored procedures. Vendors like Oracle and FirstSQL allow you to use Java as an alternative.
But there is no such movement away from using SQL for query processing. Yet the language is clearly inadequate, not only because of the extent of the dialects that are supported but also in the way that it allows the execution of very poorly formed code (which is why database optimisers have SQL rewrite capability).
Arguably this is a good thing - it allows novice programmers to still create useful queries - but it leads to bad habits and can hardly be considered a sound premise.
The fact is that we won't be saying goodbye to SQL any time soon but it is surely becoming over-bloated and it is not the panacea that the marketing departments of some suppliers would have us believe. Companies making buying decisions need to recognise that large numbers of SQL extensions make SQL a lock-in just as much as proprietary operating systems or hardware.