Terwijl Progress net 24 miljoen dollar heeft neergeteld voor Excelon, leverancier van xml-gereedschap en -databeheer, fulmineert Michael Stonebraker tegen xml-databases. De uitvinder van de Ingres-database ziet niets in dergelijke ordeningssystemen van dynamische gegevens.
Excelon, in 2001 ontstaan uit een fusie tussen C-Bridge en Excelon, is gespecialiseerd in beheer van databeheer van en gereedschap voor Java en xml. De onderneming opereert hevig in het laboratorium van webdiensten, en is overtuigd voorstander van xml-databases in de tussenlaag tussen gegevens in legacy systemen en webapplicaties. Daarom heeft Progress eind oktober Excelon ingelijfd. Deze 4gl-exponent (vierde-generatietaal) heeft met dochter Sonic Software een sterke speler neergezet op de markt van applicatie-integratie. Progress-ceo Joseph Alsop meent dat Sonic en Excelon veel aan elkaar kunnen hebben.
Lelijke eendjes
Ruim dertig leveranciers hebben een native xml-database op het menu staan, met de Tamino-server van Software AG aan top. Michael Stonebraker ziet er niet veel in. Deze database-goeroe (en tegenwoordig MIT-professor Computer Sciences) sprak op het vijftienjarige jubileum van de Ingres User Group Nederland op 22 november in Amsterdam. In 1972 bedacht hij, als wat wij zouden noemen aio (assistent in opleiding), de Ingres-database.
Als Larry Ellison niet zo doortrapt was geweest ("hij liet op de doos zetten dat de database bepaalde eigenschappen had, met in heel kleine lettertjes: niet beschikbaar in deze release") en als IBM met DB2 niet had gekozen voor SQL, maar voor het betere Quel, had Ingres nummer 1 kunnen zijn in plaats van Oracle, betoogt Stonebraker. Later die dag ondersteunt databasekenner van Hollandse makelij Rick van der Lans hem impliciet: "SQL won het van het op zich betere Quel. Vaak voeren in ict-land de lelijke eendjes de boventoon."
Tussen neus en lippen door liet Van der Lans ook weten weinig te voelen voor xml-databases. Stonebraker had eerder die dag daarvoor munitie aangedragen. De Amerikaan betoogde dat xml een uitstekende uitwisseltaal is en het daarbij moet laten. "Het is uitgevonden door documentbeheerders, niet door databeheerders, en dat is te merken. Als ik een SAP-applicatie ben en jij bent een Siebel-toepassing, is xml een uitstekend middel voor uitwisseling van documenten. Dergelijke documenten gaan namelijk automatisch en ongewijzigd door firewalls heen. Maar om xml te gebruiken om je data op slaan?"
Schone dood
In een relationele database stel je tevoren de schema’s vast, zodat geen semantische verwarring kan ontstaan (zoals ‘bedoelen we hetzelfde met velden’). Bij xml is dat niet mogelijk; het schema wordt aan het eind vastgesteld. "Dat levert een uiterst complex datamodel op", aldus Stonebraker. "Codasyl is daarbij heilig."
Conference on Data Systems Language was in de jaren vijftig van de vorige eeuw een organisatie van het Amerikaanse ministerie van Defensie die onder andere de aanzet tot Cobol heeft gegeven. Codasyl probeerde eenheid te brengen gedurende de slag om de relationele database, maar kwam met een dermate complex voorstel dat een schone dood direct in het verschiet lag.
Document type description (dtd), dat het type document beschrijft, is volgens Stonebraker ook niet meer dan dat: de beschrijving van een model document, zeker niet van data. "Hoe moet je dat gebruiken om een database in te richten? Dtd zal nooit als een schema worden geaccepteerd."
Verschillende soorten
Is Stonebraker stellig over xml-databases ("wie de geschiedenis niet begrijpt, is gedoemd haar te herhalen"), ook over webdiensten heeft hij twijfels. Dan immers gaat het om ketens van diensten die xml en/of Soap gebruiken. Onbetrouwbaarder volk kun je je vanuit dataperspectief nauwelijks voorstellen.
Gezien de verschillende toepassingen van data is het volgens Stonebraker waarschijnlijk dat er verschillende soorten databases komen, of zich al ontwikkelen. Met de typische architectuur van een datapakhuis voor ogen is makkelijk in te zien dat in de wereld van elektronische handel, waarbij tal van systemen, in welke exotische taal dan ook geschreven, met elkaar trachten te communiceren, typische oplossingen gaan ontstaan.
Teus Molenaar
