Relationeel of XML

Indien u XML-documenten in een database wilt opslaan, kunt u momenteel kiezen uit grofweg twee oplossingen. U kunt ze gewoon in een SQL-database, zoals Oracle, SQL Server of DB2, opslaan. Of u kunt voor een XML-databaseserver kiezen, zoals Tamino of eXcelon. 
Uiteraard zijn er vele redenen waarom de ene dan wel de andere strategie gekozen dient te worden. In deze column zal er slechts één belicht worden. 

Ter informatie: omdat XML-documenten qua structuur zeer complex kunnen zijn, worden ze bij het opslaan in relationele databases opgebroken in een aantal rijen verdeeld over diverse tabellen. Een XML-document wordt dan bij het ophalen weer gereconstrueerd. Dus bij het opslaan en ophalen wordt een vertaalslag uitgevoerd: van XML naar rijen en andersom. Een XML-databaseserver daarentegen slaat de XML-documenten in hun oorspronkelijke vorm op. Hier vindt dus geen vertaalslag plaats.

Een groot voordeel van een XML-databaseserver is dat niet alle documenten precies dezelfde structuur hoeven te hebben. Veronderstel dat we beschrijvingen van vliegtuigen willen registreren. Ongetwijfeld zullen vele vliegtuigen vergelijkbare specificaties hebben. Voor allemaal zal bijvoorbeeld het aantal motoren geregistreerd moeten worden (al is dat getal voor sommige gelijk aan nul) en het gewicht. Maar voor veel vliegtuigtypes zijn speciale specificaties noodzakelijk. Bijvoorbeeld, voor vliegtuigen van het type Concorde zijn ongetwijfeld andere specificaties relevant dan voor het type PiperCub. Het is zelfs zo dat elk individueel vliegtuig speciale specificaties kent. Denkt u maar aan privé-vliegtuigen die zijn ingericht naar de wensen van de eigenaar, of denk aan vrachtvliegtuigen die speciaal ontwikkeld zijn voor het vervoeren van één soort apparaat. 

In relationele termen gesproken, betekent dit dat we tabellen krijgen met zeer veel kolommen die voor vele records met de null-waarde gevuld zullen zijn. Een dergelijke tabel zal er uitzien als een gatenkaas. Indien het aantal specificaties hoog is, kunnen we bij sommige producten zelfs tegen een beperking aanlopen: teveel kolommen. Als alternatief zouden we voor elk vliegtuigtype een aparte tabel kunnen bouwen. Maar, als we dan denken aan die speciaal ontwikkelde vliegtuigen, dan zou er een situatie kunnen ontstaan, waarbij sommige tabellen slechts één of twee records bevatten. In dat geval zal onze relationele databaseserver verre van ideaal blijken te zijn.

Relationele databases zijn namelijk goed in het opslaan van veel van hetzelfde, maar niet in het opslaan van veel verschillende zaken. Al hun interne algoritmes, bijvoorbeeld voor opslag, toegang en buffermanagement, zijn gericht op het werken met veel records met een identieke structuur. Indien we een situatie zouden hebben waarin elke tabel slechts een beperkt aantal rijen zou bevatten, dan krijgen we dat wel aan de praat, maar er is dan sprake van een oneigenlijk gebruik van zo'n databaseserver.

XML-databaseservers zijn juist erg sterk in het omgaan met veel verschillende soorten documenten. Als er voor elk individueel vliegtuig een unieke verzameling specificaties bestaat, kan voor elk een apart XML-document gecreëerd worden. Al deze XML-documenten zullen verschillen, maar ook overeenkomsten hebben. We zullen nog steeds queries kunnen afvuren op de overeenkomstige specificaties, zoals Geef alle vliegtuigen met meer dan twee motoren of Geef alle vliegtuigen met meer dan 100.000 vlieguren. Maar we zullen ook queries kunnen stellen gericht op de uniekere specificaties: Geef alle vliegtuigen met een bad aan boord.

Indien u in een omgeving zit die vergelijkbaar is met de bovenstaande situatie, zou ik u aanraden eens naar XML-databaseservers te kijken. Zij hebben iets te bieden, wat de klassieke databaseservers niet ondersteunen.