Licht op SQL-‘light’

"Ik vraag mij af wat precies een SQL-‘light’ versie is, en op welke wijze die een verbetering vormt ten opzichte van de bestaande SQL-implementaties."Rob Verschoor reageert op Rick van der Lans’ pleidooi voor een dergelijke ‘light’ versie.

“Met interesse heb ik uw column ‘SQL met de S van slank’ (Computable, 14 juni) gelezen. Hierin suggereert u dat het uitbrengen van een ‘light’ versie van SQL nuttig zou zijn, omdat de bestaande SQL-dialecten te complex zouden zijn. Het ontgaat mij echter geheel hoe een ‘light’ versie van SQL dit probleem zou kunnen oplossen. Als onder ‘light’ wordt verstaan ‘een beperkte gestandaardiseerde subset van de SQL-taal’, dan bestaat die allang: de ‘entry-level’ van SQL-92 wordt inderdaad door de meeste leveranciers ondersteund. Het is mij niet duidelijk waarom die niet zou voldoen.
Los daarvan is er uiteraard een reden waarom die verschillende dialecten zich hebben ontwikkeld: dergelijke extra functionaliteit blijkt in de praktijk domweg gewenst te zijn, hoe spijtig het bestaan van niet-overdraagbare dialecten ook mag zijn. Ik vraag mij derhalve af wat u precies bedoelt met een SQL-‘light’ versie, en op welke wijze die een verbetering vormt ten opzichte van de bestaande SQL-implementaties. Nadere detaillering zie ik dan ook met belangstelling tegemoet. Overigens constateer ik dat ook in uw column de dynamiek c.q. chaos van het huidige XML-landschap zichtbaar is: u noemt uitsluitend Xquery als XML-taal-in-wording, maar gaat hier voorbij aan het feit dat Xquery slechts een van de diverse standaarden in potentie is. Ook XQL (volgens velen op dit moment de ‘de facto’ standaard) en XML-QL zijn officieel als standaarden voorgesteld bij het W3C; welke er uiteindelijk door het W3C zullen worden aanbevolen is geheel onduidelijk. Los daarvan wemelt het nog van andere varianten als Xpath, Quilt, DQL enzovoorts, waarmee ik maar wil zeggen dat Xquery slechts een van de vele is."
 
Rob Verschoor, Certified Sybase Professional

Rationeel antwoord op overcapaciteit SQL

SQL blijft ook mijn aandacht trekken. Ik heb enkele boeken over SQL geschreven en dan blijft zo’n onderwerp altijd boeien. Daarom wil ik ook graag reageren op de ingezonden brief van Rob Verschoor.
In feite heeft hij drie vragen. De eerste vraag is wat ik met een ‘SQL-light’ versie bedoel en op welke wijze dit een verbetering vormt ten opzichte van de bestaande SQL-implementaties. In zijn brief vraagt hij zich tevens af of het door mij gesignaleerde overdraagbaarheidsprobleem opgelost wordt als een ontwikkelaar zich beperkt tot het ‘entry-level’ van SQL-92. Tenslotte heeft hij een vraag over de verschillende XML-gebaseerde databasetalen.
Met een ‘light’-versie bedoel ik een SQL-product dat alleen klassieke databasefunctionaliteit ondersteunt en geen faciliteiten voor, bijvoorbeeld, XML en/of object-relationele concepten. Voor de meeste administratieve applicaties zal dit voldoende zijn. De bekende databaseservers kunnen we zeker niet als ‘light’ aanduiden, die hebben eerder een overvloed aan functionaliteit. Maar ook al gebruiken we die functionaliteit niet, ze is echter wel aanwezig en kan ons zelfs tegenwerken.
Een voorbeeld aan de hand van een vergelijking. Veronderstel dat ik een forse auto koop met drie rijen banken en gewichtsstabilisatoren – een minibus dus. Als ik altijd de enige passagier van die auto ben en deze nooit zwaar belaad, dan heb ik irrationele overcapaciteit aangeschaft, want de meeste functionaliteit gebruik ik nooit. Deze functionaliteit maakt de auto wel duurder en ongunstig in gebruik, want de auto moet vele kilo’s extra gewicht over het asfalt heen slepen. Een kleine tweezitter is dan waarschijnlijk efficiënter.
Hetzelfde geldt voor de databaseservers waaraan door de jaren heen veel technologie toegevoegd is. De meeste applicaties hebben echter slechts een deel van al die functionaliteit nodig. En net als in de hierboven besproken auto is die functionaliteit er wel, waardoor de databaseservers zware processen geworden zijn. Je kunt je beperken tot een subset van de SQL-taal, maar die ongebruikte functionaliteit draait wel mee. Vandaar mijn wens voor SQL-‘light’ versies waar niet veel extra functionaliteit in zit. Deze behoren dan goedkoper te zijn, de handleidingen zullen dunner zijn, databasebeheerders zullen minder parameters hoeven in te stellen, de optimaliseerders hoeven met minder aspecten rekening te houden, en zo kan ik nog wel even doorgaan.

Toepassing subset

Er is altijd wat te zeggen voor beperking tot een overdraagbare subset van SQL, zoals Verschoor schrijft. Wel moeten we ons dan bewust zijn van twee aspecten. Ten eerste sluiten we ons hiermee af van veel functies die het gebruik van een SQL-producten kunnen versnellen. En ook al kiezen we een kleine subset, dan zal het toch nog lastig zijn echt overdraagbare SQL-applicaties te creëren. Bijvoorbeeld, de beruchte ‘null’-waarde is niet door elke leverancier identiek geïmplementeerd. Probeer maar eens de volgende subquery "select * from tabel1 where kolom1 not in (subquery)". Als in een bepaalde rij de waarde van kolom1 gelijk is aan de ‘null’-waarde, en tegelijkertijd het resultaat van de subquery leeg is, dan zullen bijvoorbeeld DB2 en Oracle verschillende resultaten geven. Ook het rekenen met datums is niet door iedereen gelijkwaardig geïmplementeerd.
Het toepassen van een subset van SQL kan kortom nuttig zijn, maar er kleven wel degelijk nadelen aan en het bepalen van de perfect overdraagbare SQL-subset is een grotere uitdaging dan vaak gedacht wordt. Niet alleen moet bepaald worden of de syntax gelijk is, maar de verwerking van de syntax (ofwel de semantiek van de taal) moet ook bestudeerd worden. En dat laatste halen we niet eventjes uit de handleidingen.
De derde vraag van de heer Verschoor betreft XML en SQL. In mijn column gaf ik aan dat XQuery nog geen bedreiging vormt voor SQL. Verschoor meldt dat er ook nog andere XML-gerelateerde talen zijn, zoals Quilt, XPath en XQL. Ik heb me in mijn column alleen gericht op XQuery, omdat die nog minder de hegemonie van SQL kunnen bedreigen als XQuery.
Toch enkele opmerkingen over enkele van deze talen. Quilt was het voorstel van Donald Chamberlin van IBM, maar die werkt nu aan XQuery. Voor hem is het Quilt-project afgelopen. XPath kan geen databasetaal genoemd worden. Zelfs de betiteling ‘query’-taal zou nog te sterk zijn. Het is een taaltje om bepaalde delen van een XML-document te identificeren. Dat is niet voldoende voor een ‘query’-taal. XPath zal weliswaar binnen andere talen gebruikt worden, zoals SQL en XQuery, maar dat maakt haar nog geen databasetaal. Varianten van XQL zijn wel reeds door enkele leveranciers geïmplementeerd, maar het is zo goed als zeker dat veel leveranciers die taal op de lange termijn door XQuery zullen vervangen.
SQL kan alleen in haar hegemonie bedreigd worden, als enkele grote, bekende databaseleveranciers een nieuwe databasetaal implementeren.
Zoals het er nu uitziet, is Xquery de enige mogelijke kandidaat.
 
Rick van der Lans