We moeten wel met SQL

De afgelopen weken heb ik uitvoerig de nadelen van SQL langs zien komen in Computable. Ik ben het grotendeels eens met Chris Date, Han Zijlstra en anderen: SQL, in welk dialect dan ook, is verre van perfect. Helaas is het de enige database taal die we op grote schaal tot onze beschikking hebben. Wat echter nog een groter probleem is dan SQL met zijn beperkingen, is de kwaliteit van de databases en de database programmatuur.
Alle bekende databases (Oracle, DB2, ...) zijn relationele databases. Definieer een tabel A met een unieke primary key, en de database engine zorgt ervoor dat deze tabel te allen tijde een unieke sleutel heeft; indien gewenst wordt deze sleutel gegenereerd. Definieer een tabel B met een foreign key die uit de primary key van tabel A bestaat, en de database engine zorgt ervoor dat er geen gekke relaties tussen de tabellen A en B kunnen bestaan.
Echter, de meeste databases worden als elektronische kaartenbak gebruikt. Sleutels zijn er niet, als je geluk hebt is er een substituut (een unieke index). Relaties tussen tabellen zijn niet te vinden in de database; daarvoor moet je de SQL-code van de applicatie onderzoeken.
BCNF (Boyce/Codd Normal Form) of de derde normaalvorm? De meesten hebben geen idee wat dat is. Maak lekker veel tabellen, dupliceer veel data, liefst in kolommen die een iets andere definitie hebben (zoals karaktervelden van 25 posities in het originele veld en 20 posities in het afgeleide veld). Maak batches en triggers die pogen alle tabellen te synchroniseren, en je database spaghetti is compleet! Het dupliceren van data gebeurt niet alleen vanwege de performance, maar ook vanwege het gemak of het gebrek aan kennis met betrekking tot database ontwerp. En dit ligt echt niet aan de gebreken van SQL, maar aan de gebreken van de SQL programmeurs!
Om een voorbeeld van Han Zijlstra te nemen: met een SQL uitbreiding als Oracle's PL/SQL is het mogelijk een query met outer joins op te splitsen in een select zonder outer joins met daaromheen een stukje code, waarin de gevallen van wel of geen match met een bepaalde andere tabel overzichtelijk in een IF-THEN-ELSE structuur kan worden afgehandeld.
Kun je SQL de schuld geven van null waarden in een sleutel? Misschien is het niet goed dat het mag in SQL, maar de database ontwerper had eenvoudig een 'not null' restrictie op dat sleutelveld kunnen zetten. Het is wel heel makkelijk om SQL de schuld te geven van dit soort menselijke fouten!
Net als Han Zijlstra hoop ik dat SQL binnenkort wordt opgevolgd door een betere databasetaal, en dan liefst één die zo uitgebreid is dat elke database leverancier hem onveranderd opneemt in zijn produkten. Want SQL mag dan een standaard zijn, elke database leverancier heeft daar zijn eigen uitbreidingen op bedacht, zodat SQL niet overdraagbaar is van database A naar database B.
Er is echter nog geen universeel beschikbare opvolger van SQL. Totdat deze er is, moeten we het met SQL doen. Wanneer database ontwerpers en programmeurs nu al betere databases en database applicaties maken, dan zijn we misschien klaar voor de opvolger van SQL als deze beschikbaar komt.

 
Frank Heikens, ICT consultant