Er was ooit een tijd dat het migreren naar een andere databaseserver nagenoeg onmogelijk was. Producten als IMS, IDMS en Model 204 waren zo verschillend dat applicaties geheel herschreven moesten worden.
Dit totaal ontbreken van overdraagbaarheid was een van de argumenten voor organisaties om in de jaren tachtig over te schakelen op SQL. Toen nog niet zo bekende producten als SQL/DS (van IBM), Oracle en Informix werden geïntroduceerd en ondersteunden allemaal deze gestandaardiseerde taal. Het tijdperk van SQL was begonnen.
Uiteraard bestonden er wel verschillen tussen de diverse producten, maar een migratie was met een minimale inspanning te realiseren. De functionaliteit van SQL was dermate beperkt dat een eventueel verschil met applicatiecode snel weggewerkt was. Nu, meer dan twintig jaar later, moeten we concluderen dat dit niet meer het geval is. Bekende commerciële producten als IBM’s DB2, Microsoft SQL Server, Oracle, maar ook open source systemen als MySQL en PostgreSQL zijn sterk uit elkaar gegroeid. Een migratie is haast niet meer te doen.
Wat is er in die tussenliggende jaren gebeurd? In het begin bleven de leveranciers de SQL-standaard redelijk netjes volgen. De een was wat verder met het implementeren van de standaard dan de ander, maar iedereen zat wel op hetzelfde pad. In de tweede helft van de jaren negentig hadden de leveranciers het idee dat de markt vroeg om objectrelationele concepten. Deze werden snel toegevoegd, terwijl de standaard nog niet klaar was. Iedereen implementeerde het dus ook op een andere wijze. En hiermee was de verwijdering begonnen.
Als we vandaag enkele producten naast elkaar leggen, zien we kleine, maar helaas ook heel grote verschillen. Voorbeelden van kleine afwijkingen zijn dat de eigenschappen van het datum-datatype per product variëren en dat de NULL-waarde verschillend geïmplementeerd is. Maar hier is met wat handig programmeerwerk wel mee te leven. Het probleem zit in die grote verschillen.
Bijvoorbeeld, alle leveranciers ondersteunen momenteel de opslag en verwerking van XML-documenten binnen de database. Iedereen heeft dit echter anders geïmplementeerd. Dus als u ook maar iets met XML binnen een van de bekende SQL-databaseservers doet, dan is die code niet overdraagbaar.
Ook de relatie tussen de database en het internet is versterkt. De een kan HTTP-aanroepen direct vanuit de databaseserver verwerken, de ander kan slechts de URL’s opslaan in een database.
Sommige producten kunnen webservices achter SQL-tabellen verstoppen. Hierdoor leidt het bevragen van een tabel in feite tot het aanroepen van een webservice. Maar de code om dit te realiseren verschilt enorm. Zeker nu veel organisaties zwaar gaan investeren in service oriented architectures zou het handig zijn als elke leverancier dezelfde oplossing had gekozen.
En dan praten we nog niet eens over de taal om stored procedures en triggers te specificeren, de reeds genoemde objectrelationele concepten.
Er wordt wel eens gezegd dat het niet meer uitmaakt welke databaseserver men kiest, het is toch lood om oud ijzer. Functioneel klopt dat wel, maar niet als we kijken naar hoe die functies aangeroepen worden. De databaseservers zijn de laatste jaren sterk uit elkaar gegroeid. En wel zo sterk dat grote stukken code, die nu voor de ene databaseserver geschreven worden, volledig herschreven zullen moeten worden als de applicatie gemigreerd wordt.
Je beperken tot alleen die functies die elke leverancier geïmplementeerd heeft, is ook een naïeve gedachte. Hiermee zou te veel functionaliteit worden buitengesloten. Het lijkt erop dat we moeten accepteren dat databaseservers gewoonweg niet meer overdraagbaar zijn. Als dit maar niet de toekomst is van andere standaarden, zoals Java, SOAP of Linux.< BR>
Rick F. van der Lans is onafhankelijk adviseur, een internationaal bekend spreker en auteur van diverse boeken, tevens gespecialiseerd in softwareontwikkeling, datawarehousing en internet.
