Het scheiden van databasemanagementsysteem en applicatie is al lang gemeengoed. De scheiding is logisch, niet fysiek, zoals verhalen over ‘multi-tier’ architecturen soms lijken te suggereren.
De eerste databases waren leveranciersspecifiek. Zij konden op verschillende manieren geïmplementeerd worden en boden verschillende functies. Wie gegevens wilde bewerken, moest dat steeds op een andere manier programmeren. Het relationele database-model moest de situatie eenvoudiger maken. Dat is ook gebeurd. Met SQL kregen we een standaardtaal voor database-toegang.
Helaas houdt de IT-industrie niet van standaarden, al is er door Internet tegenwoordig meer druk om wel volgens de standaarden te werken. In de meeste gevallen implementeren leveranciers de standaard maar tot op zekere hoogte, waarna ze extra functies toevoegen. Zodra deze worden gebruikt, is er sprake van een leveranciersspecifiek systeem.
Zelfs met een echte standaard als ‘pure’ SQL zijn er genoeg incompatibiliteiten. Voor het formaat van de vragen en antwoorden tussen applicatie en dbms bestaan bijvoorbeeld geen standaarden, ook al bestaat de inhoud uit puur SQL. Er is dan ook een hele categorie middleware om verschillende relationele datamanagementsystemen op elkaar aan te sluiten, met verschillende subsystemen voor communicatie en een heel scala aan programmeertalen. Zelfs in een ‘pure’ omgeving is het overdragen van een applicatie van het ene rdbms naar het andere geen sinecure.
Het probleem is eenvoudiger voor simpele dynamische queries. Daarbij worden SQL-statements gecomprimeerd (nog meer kans op incompatibiliteit) en aan het rdbms doorgegeven ter interpretatie. Voor ‘multi-user’-transactiesystemen is dit mechanisme echter niet efficiënt. Al bij de eerste rdbms-producten, die nog in ’time-shared’-omgevingen als VMS en Unix draaiden, realiseerde men zich al snel dat een aanzienlijke winst in prestaties te behalen was door repetitieve SQL-statements vooraf te compileren en in de database op te slaan. In dat geval wordt het SQL-statement in het programma vervangen door de aanroep van een opgeslagen SQL-procedure, ook weer een bron van incompatibiliteiten. Al snel beseften leveranciers dat ze ook transactiediensten en procedurele functies in de database konden opslaan, zodat deze door het rdbms konden worden uitgevoerd.
De introductie van de client/server-architectuur was voor de rdbms-leveranciers relatief eenvoudig, omdat de noodzakelijke scheiding tussen bedrijfslogica en gegevenslogica al eerder was gerealiseerd. Het enige dat nodig was, was de introductie van middleware waarmee de server-procedures waren aan te roepen vanaf een client op het netwerk, een speciaal soort ‘remote procedure call’. De interface moest ervoor zorgen dat er een connectie kon worden opgezet (sessiebeheer), dat fouten werden afgehandeld en dat de beveiliging geregeld werd. En natuurlijk moest het mogelijk zijn gegevens tussen de client en de server uit te wisselen. De middleware moest een API hebben, zodat programmeertalen hun variabelen konden afbeelden op de werkruimte van de middleware op de server.
De mainframes waren nog steeds hetzelfde. De client (Cics) werd gescheiden van de database (DB2) met behulp van partitionering, met de bijbehorende leveranciersspecifieke precompilatie, planning en dergelijke.
Enkele jaren geleden probeerde de SQL Access Group een set standaarden op te stellen voor toegang tot relationele databases. Ze konden het niet eens worden. Wanhopig vatte Microsoft de stier bij de horens en doopte de tot dan toe ontwikkelde standaard om tot Open Database Connect (Odbc). Deze ‘de facto’ standaard definieert een specifieke subset van SQL en ook een verzameling api’s voor interconnectie, foutafhandeling, naamgeving en dergelijke. De leveranciers van programmeertools ontwikkelden Windows-producten die konden praten met elke relationele database met compatibele Odbc-functies.
Leveranciers van databases implementeerden Odbc met tegenzin en behielden hun eigen extensies, vooral die op het gebied van ‘stored procedures’. Odbc was na enkele jaren succesvol voor algemene SQL-programma’s, maar niet voor applicaties die werkten met specifieke functies van Oracle, Sybase en dergelijke. Dit betekent in de praktijk dat Odbc kan worden gebruikt voor query-tools zoals producten voor ‘business intelligence’, maar alleen bij eenvoudige transactiesystemen. De belangrijkste zakelijke applicaties kunnen om redenen van prestaties immers niet zonder de leveranciersspecifieke uitbreidingen.
Is dit nog wel zo? Hardware is spotgoedkoop, software-ontwikkeling is duur. Een applicatie die alleen Odbc (of Jdbc) gebruikt, zou meer hardware nodig hebben dan een leveranciersspecifiek equivalent. In ruil daarvoor wordt het mogelijk om te kiezen uit een heel scala aan programmeertools, besturingssystemen en dbms’en. Ik denk dat de hardware-kosten volgend jaar al zo laag zijn dat de extra investering geen probleem meer is, en dat Odbc kan worden gebruikt voor de meeste transactie-applicaties, de meest complexe applicaties misschien daargelaten.
