De monolitische databaseserver

Vroeger was een databaseserver gewoon een databaseserver. Het was een brok software dat verantwoordelijk was voor het opslaan, terughalen en beheren van gegevens. Niets meer dan dat. Tegenwoordig zijn databaseservers eerder zevenkoppige monsters waarvoor we drie meter handleiding door moeten worstelen voordat we alle functies bestudeerd hebben. Bijna alle leveranciers (inclusief Oracle) hebben door de jaren heen steeds meer functies aan hun databaseserver toegevoegd. Dit landje kapen is een door hun zelf verkozen route, maar moeten wij als klant daar wel blij mee zijn?

Larry Ellison was ooit de auteur van een klein, dun boekje waarin de mogelijkheden van SQL beschreven werden. Ik heb het nog in de kast staan. Het boekje, dat nog geen één centimeter dik is, werd meegeleverd met elke installatie van de Oracle databaseserver. Dit was het tijdperk van Oracle versies 4 en 5. Het leven was toen nog eenvoudig. De taken van een databaseserver waren duidelijk. Ook de scheidslijn tussen de applicatie en de databaseserver was haarscherp. We mopperden alleen fors over het gebrek aan integriteitregels.

Die klaagzang heeft er toe geleid dat we uiteindelijk foreign keys, check-constraints en triggers kregen. Ook gedistribueerde faciliteiten, zoals two-phase commit, werden toegevoegd. Dit waren ook allemaal functies die in een databaseserver thuishoorden. Als vandaag een nieuwe databaseserver zonder dit soort functies op de markt verschijnt, beschouwen we haar als onvolledig.

Het voordeel voor de leveranciers was dat elke keer weer een nieuwe versie door de klanten aangeschaft moest worden. Kassa! Echter, op een gegeven moment waren de door de klanten gevraagde databasefuncties op. Maar de leveranciers wilden uiteraard wel hun kassa's laten rinkelen. Er moesten nieuwe versies uitgebracht worden, dus er moesten nieuwe functies bedacht worden. 

Het effect is dat nieuwe versies van databaseservers, zoals Oracle's versies 8 en 9, uitgebreid zijn met Internet-technologie, OO-concepten, applicatieservers, OLAP-functionaliteit, datamining mogelijkheden en zelfs faciliteiten voor message queuing. Deze functies hebben in principe niets met gegevensbeheer te maken. Het zijn taken die we meestal laten uitvoeren door andere softwareproducten. 

Hebben wij als klanten daar ooit om gevraagd? Of zijn dit allemaal functies die we liever in losstaande producten geïmplementeerd zien? Deze stop-alles-maar-in-de-database aanpak heeft wel degelijk nadelen. Bijvoorbeeld, de klant heeft mogelijk reeds een product in huis met diezelfde functionaliteit. Als dit dan in de databaseserver wordt geïmplementeerd, ontstaat meestal een conflict: gebruiken we het losstaande product of de nieuwe module van de databaseserver? Hoe meer functies in de databaseserver, hoe groter de kans dat we niet alles zullen gebruiken. En wordt onze performance niet onnodig verslechterd vanwege de voor ons irrelevante functies? Betalen we trouwens niet teveel? Een ander nadeel is dat veel van die nieuwe functies niet gestandaardiseerd zijn. Gaat u ze gebruiken, dan wordt de lock-in steeds groter.

In dit tijdperk van componenten is het vreemd dat de databaseleveranciers dit soort functievretende monolieten bouwen. Het zou nuttiger zijn als ze zich bij de doorontwikkeling van hun databaseservers richten op het sneller, robuuster en efficiënter maken van deze producten, dan op het toevoegen van allerlei modules die we liever in andere producten zien. 

Databaseleveranciers, hou je nu maar bij je leest. Perfectioneer de gegevensbeheersfuncties van uw databaseserver en stop al die andere functies in aparte producten. Het wordt voor klanten dan eenvoudiger een product te beoordelen, te doorgronden en in te zetten. Laat het bouwen van Zwitserse messen maar aan de Zwitsers over.