Het is al weer enkele jaren geleden dat ISO en ANSI de nieuwste SQL-standaard uitbrachten. SQL3 is de derde, volledig nieuwe versie en vervangt SQL2 uit 1992, die op haar beurt weer de opvolger was van de eerste uit 1987.
SQL is momenteel onvoorstelbaar populair. Bijna elke organisatie heeft minimaal één informatiesysteem draaien waarbinnen SQL gebruikt wordt. SQL heeft in haar eigen markt van databasetalen een dusdanig monopolie gecreëerd, waar programmeertalen als C++, Java en Visual Basic jaloers op zijn. Maar gaat het, ondanks die populariteit, wel goed met SQL? Hoe staat het eigenlijk met de overdraagbaarheid van SQL-code, en zijn er concurrenten in aantocht?
Standaarden worden onder andere ontwikkeld om code overdraagbaar te maken. Dit geldt slechts ten dele voor de SQL-standaard. Door de jaren heen zijn de SQL-dialecten van de verschillende producten uit elkaar gegroeid. Vooral de toevoegingen van ’triggers’ en ‘stored procedures’ eind jaren tachtig, object-relationele concepten in de tweede helft van de jaren negentig, en de ondersteuning voor XML van de laatste twee jaar, hebben er toe geleid dat de mate van overdraagbaarheid afgenomen is. Elke leverancier heeft deze functionaliteit op eigen wijze toegevoegd.
Uiteraard zijn er wel enkele overeenkomsten, maar de verschillen overheersen. De hoofdreden is dat in de meeste gevallen er nog geen standaard bestond waarin deze concepten gedefinieerd waren, terwijl de leveranciers wel de functionaliteit wilden implementeren. Ze moesten dus wel zelf iets bedenken.
Leveranciers hebben allerlei creatieve oplossingen bedacht voor de toevoeging van XML. Ieder op zijn eigen wijze. Sommige naïeve vertegenwoordigers merken trots op dat hun product twee standaarden ondersteunt: SQL en XML, en daardoor dus overdraagbaarheid biedt. Maar zo simpel ligt dat niet. Overdraagbaarheid ontstaat als code zonder wijzigingen draait op een databaseserver van een andere leverancier, en dat is niet het geval.
We kunnen ons afvragen of al die toevoegingen echt wel nodig zijn. De producten zijn hierdoor uitgegroeid tot mastodonten. Er moeten vele handleidingen doorgespit worden, wil men alle functionaliteit van een doorsnee databaseserver gezien hebben. Het is begrijpelijk dat sommige bedrijven daardoor op zoek gaan naar ‘slankere’ databaseproducten, zoals my SQL, Berkeley DB en Solid. Natuurlijk kunnen deze producten qua potentiële prestaties en schaalbaarheid niet wedijveren met de grote jongens als DB2, Oracle 9i en SQL Server. Maar niet iedereen heeft zoveel prestaties en schaalbaarheid nodig. En ik zou zelfs durven beweren dat het merendeel van de bedrijven op deze planeet dit niet vragen.
De bekende SQL-producten bieden dus veel, misschien wel een overdaad aan functionaliteit, maar tegen een bepaalde prijs en ten koste van de overdraagbaarheid.
SQL kent geen concurrenten. Er zijn wel andere databasetalen, maar als we een taartdiagram maken met de marktaandelen van alle databasetalen, dan neemt SQL bijna de hele taart voor zijn rekening.
Heel ver aan de horizon, in het land van XML, wordt wel aan een nieuwe databasetaal gewerkt, genaamd XQuery. De doelstelling bij de ontwikkeling van deze nieuwe taal is dat ze minimaal de functionaliteit van SQL ondersteunt, aangevuld met een betere ondersteuning voor het omgaan met hiërarchische XML-documenten. Het is bekend dat verscheidene databaseleveranciers bezig zijn met het implementeren van XQuery. Maar we kunnen nog niet zeggen dat ze bedreigend voor SQL’s hegemonie beginnen te worden.
Een van de twee nog in leven zijnde ontwikkelaars van SQL, Donald Chamberlin, is van mening dat we SQL al voldoende functioneel opgerekt hebben. We doen er nu dingen mee, waarvoor de taal aanvankelijk nooit bedacht is. Volgens hem is het tijd voor een opvolger. De rek is er uit.
Kortom, hoe staat het nu eigenlijk met SQL? De taal, die bij haar introductie door zo velen zo zwaar bekritiseerd werd, is een kaskraker geworden. De dominantie van SQL zal op korte termijn niet aangetast worden. Echter, SQL is niet altijd SQL. Iedereen implementeert zijn eigen SQL-dialect, waardoor het met de overdraagbaarheid slecht gesteld is. Kunnen we dus nog wel spreken van één SQL-taal?
De verschillen tussen de dialecten zitten voornamelijk in de toevoegingen van de laatste jaren die geleid hebben tot complexe implementaties. De vraag is of bedrijven hierdoor zullen gaan overwegen om voor enkele van hun applicaties de bekende databasekolossen opzij te schuiven en daarvoor in de plaats slanke, overdraagbare databaseservers in te zetten. Als ik IBM, Microsoft of Oracle zou zijn, dan zou ik SQL-‘light’ versies gaan uitbrengen. Die moeten dan goedkoper zijn, simpel te installeren zijn, overdraagbaar zijn en niet zoveel functionaliteit hebben, zodat een programmeur zich niet maanden in een klooster hoeft terug te trekken om alle handleidingen door te nemen.
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
