Relationele of documentdatabase? | woensdag.nl

Relationele databases en documentdatabases slaan gegevens op volgens verschillende uitgangspunten. Lees hoe die keuze invloed heeft op dataconsistentie, veranderende gegevensmodellen, queries en het dagelijks beheer van websoftware.

Hoe tabellen en relaties gegevens bij elkaar houden

Een relationele database verdeelt gegevens over tabellen met vaste kolommen. Denk aan een tabel voor klanten, een tabel voor bestellingen en een aparte tabel voor bestelregels. Met sleutels leg je vast welke bestelling bij welke klant hoort en welke producten op een bestelling staan. De gegevens van een product staan daardoor niet bij iedere bestelregel opnieuw opgeslagen. Dat beperkt dubbele informatie en maakt wijzigingen beter beheersbaar.

Wanneer een klant verhuist, pas je het adres bijvoorbeeld op één plek aan. Elke toepassing die het adres nodig heeft, kan daarna dezelfde waarde ophalen. Relaties tussen tabellen maak je expliciet, vaak met een primaire sleutel en een verwijzende sleutel. De database kan controleren of verwijzingen geldig zijn. Zo voorkom je bijvoorbeeld dat een bestelregel verwijst naar een product dat niet bestaat.

Deze structuur vraagt wel om zorgvuldig datamodelwerk. Een query die gegevens uit meerdere tabellen nodig heeft, gebruikt joins. Dat is krachtig, maar de logica kan ingewikkeld worden wanneer een scherm informatie uit veel bronnen combineert. Verandert het model, bijvoorbeeld doordat een bestelling voortaan meerdere afleveradressen heeft, dan moeten tabellen, applicatiecode en soms bestaande data worden aangepast. Relationeel betekent dus niet automatisch eenvoudig: de structuur maakt verbanden zichtbaar, maar vraagt om duidelijke afspraken over die verbanden.

Hoe een documentdatabase gegevens als complete objecten opslaat

Een documentdatabase bewaart gegevens doorgaans als zelfstandige documenten, vaak in een JSON-achtige structuur. Een productdocument kan bijvoorbeeld een naam, prijs, voorraadstatus, afbeeldingen en een lijst met kenmerken bevatten. Die velden staan dan bij elkaar in hetzelfde document, in plaats van verspreid over meerdere tabellen. Een applicatie kan het document in één keer ophalen en direct gebruiken voor een productpagina of API-respons.

Documenten binnen dezelfde collectie hoeven niet altijd exact dezelfde velden te hebben. Een eenvoudig product kan drie kenmerken bevatten, terwijl een maatwerkproduct er twintig heeft. Dat past goed bij gegevens die van nature variëren, zoals contentpagina’s, productconfiguraties of formulieren waarvan de velden per formulier verschillen. Het voordeel is dat je niet voor elke uitzondering meteen een nieuwe tabel of reeks lege kolommen nodig hebt.

Flexibiliteit is geen vervanging voor ontwerp. Als applicaties ongemerkt verschillende namen gebruiken voor hetzelfde veld, ontstaan documenten die lastig samen te verwerken zijn. Ook kan dezelfde klantinformatie in meerdere documenten terechtkomen. Een adreswijziging moet dan op alle relevante plekken worden doorgevoerd, tenzij je die informatie bewust apart beheert. Een documentdatabase werkt daarom het best wanneer duidelijk is welke gegevens bij elkaar horen, welke variatie is toegestaan en welke velden essentieel blijven voor de werking van de software.

Dataconsistentie en integriteit: waar mag een afwijking ontstaan?

Dataconsistentie gaat over de vraag of gegevens onderling kloppen, ook wanneer meerdere gebruikers of processen tegelijk wijzigingen uitvoeren. Relationele databases bieden hiervoor bekende hulpmiddelen, zoals transacties, unieke sleutels, verplichte velden en controles op verwijzingen. Bij een betaling kan een transactie bijvoorbeeld zorgen dat een bestelling niet wel als betaald wordt gemarkeerd, maar de bijbehorende betalingsregistratie ontbreekt. De database voert dan alle wijzigingen uit of geen ervan.

Documentdatabases ondersteunen ook transacties en validatie, maar de precieze mogelijkheden verschillen per systeem en gebruik. Vaak ligt de nadruk op wijzigingen binnen één document. Als een handeling meerdere documenten raakt, moet je nagaan hoe de database die wijziging afhandelt en wat er gebeurt bij een fout of gelijktijdige update. Een voorraadmutatie is een praktisch voorbeeld: twee kopers mogen niet allebei het laatste exemplaar krijgen doordat de applicatie eerst leest en pas later schrijft.

De keuze draait niet simpelweg om “veilig” tegenover “onveilig”. Je bepaalt waar regels worden afgedwongen: in de database, in de applicatie of in een combinatie daarvan. Databasecontroles zijn moeilijker per ongeluk te omzeilen, maar vragen om een passend schema. Applicatieregels zijn soms flexibeler, maar kunnen uiteenlopen wanneer meerdere services dezelfde gegevens aanpassen. Leg daarom per gegeven vast welke afwijkingen acceptabel zijn, welke niet, en welk onderdeel de regel bewaakt.

Een gegevensmodel dat verandert zonder de software te ontregelen

Websoftware verandert vaak stapsgewijs. Een webshop voegt bijvoorbeeld een abonnementsvorm toe, een informatieplatform introduceert een nieuw type content of een klantportaal krijgt extra profielvelden. In een relationele database is de structuur expliciet. Een nieuw veld of een andere relatie vraagt meestal om een schemawijziging en een migratie. Dat maakt de verandering zichtbaar en controleerbaar, maar vraagt planning als de database groot is of de applicatie continu beschikbaar moet blijven.

Bij een documentdatabase kun je vaak eerst nieuwe documenten met extra velden opslaan, terwijl oudere documenten die velden nog missen. Die ruimte maakt geleidelijke ontwikkeling mogelijk. De applicatie moet dan wel met beide vormen kunnen omgaan. Code die ervan uitgaat dat elk document een veld bevat, kan anders stuklopen op oudere records. Een veldnaam wijzigen vraagt bovendien vaak een overgangsperiode waarin de software zowel de oude als de nieuwe naam begrijpt.

Een praktische aanpak is om wijzigingen versieerbaar te maken. Beschrijf welke documentvormen of tabelstructuren bestaan, voeg nieuwe velden gecontroleerd toe en bepaal of oude data wordt omgezet. Niet elk optioneel veld hoeft direct in bestaande records te staan, maar essentiële gegevens mogen niet stilzwijgend ontbreken. Flexibiliteit verlaagt soms de drempel voor een wijziging; het kan ook betekenen dat technische schuld zich ongemerkt opstapelt. De beste structuur is daarom niet per se degene die vandaag de minste aanpassingen vraagt, maar degene waarvan veranderingen beheersbaar blijven.

Queries en leespatronen bepalen welke structuur praktisch is

Een database wordt niet alleen gekozen op basis van hoe gegevens eruitzien, maar ook op basis van hoe de software ze gebruikt. Maak daarom concrete lees- en schrijfpatronen inzichtelijk. Moet een productpagina snel productinformatie, varianten en actuele voorraad tonen? Haalt een beheerscherm omzet per categorie op? Worden klantgegevens vooral opgevraagd per account, of moeten rapportages gegevens over duizenden bestellingen combineren? De antwoorden beïnvloeden welke structuur en indexen nodig zijn.

Documentopslag kan efficiënt zijn wanneer een applicatie meestal complete, samenhangende documenten ophaalt. Als een scherm telkens precies één product met zijn kenmerken nodig heeft, voorkomt een passende documentstructuur dat de applicatie meerdere tabellen moet combineren. Daar staat tegenover dat het lastig kan worden om bijvoorbeeld alle producten met een bepaald kenmerk te vinden als dat kenmerk op uiteenlopende manieren is opgeslagen.

Relationele databases zijn sterk in flexibele combinaties van gestructureerde gegevens. Een query kan klanten, bestellingen en bestelregels koppelen en vervolgens filteren of groeperen. Dat is handig voor beheerschermen en rapportages, maar een query met veel joins kan onderhoudsgevoelig of traag worden als tabellen, indexen en datavolumes niet goed zijn afgestemd. Test dus met realistische gegevens en echte query’s, niet alleen met een klein ontwikkelbestand. Een keuze die op een eenvoudige demo soepel voelt, kan bij complexe filters of piekbelasting anders uitpakken.

Webshopgegevens: producten, varianten, orders en voorraad

Een webshop laat zien waarom één databasevorm niet voor ieder gegeven vanzelfsprekend is. Producten kunnen vaste gegevens hebben, zoals een artikelnummer en merk, maar ook sterk wisselende kenmerken. Kleding heeft bijvoorbeeld maat en kleur; elektronica kan vermogen, aansluitingen en technische specificaties hebben. Een document kan zulke kenmerken bij het product bewaren. Dat maakt het ophalen van een product voor de etalage overzichtelijk, zolang de naamgeving en betekenis van kenmerken voldoende consistent blijven.

Orders hebben andere eisen. Een order bevat regels, aantallen, prijzen, belastingen, aflevergegevens en een betaalstatus. De prijs op een bestaande order moet meestal de prijs op het moment van aankoop blijven, ook als de actuele productprijs later wijzigt. Daarom bewaart de software vaak een momentopname van relevante product- en prijsgegevens. Een relationeel model maakt de verbanden tussen order, regels en betalingen expliciet. Een documentmodel kan de order en zijn regels als één geheel opslaan, wat ophalen vereenvoudigt. In beide gevallen moet de applicatie bepalen welke gegevens historische snapshots zijn en welke verwijzen naar actuele informatie.

Voorraad vraagt om aparte aandacht omdat meerdere processen dezelfde aantallen kunnen aanpassen: verkoop, retouren, magazijnimport en handmatige correcties. Een ontwerp moet voorkomen dat updates elkaar overschrijven of negatieve voorraad veroorzaken als dat niet is toegestaan. Ook moet duidelijk zijn of voorraad per product, variant, magazijn of verkoopkanaal wordt bijgehouden. De keuze voor relationeel of documentgericht volgt hier uit de benodigde controles en bewerkingen, niet alleen uit de vorm van de productpagina.

Koppelingen, API’s en rapportages vragen om duidelijke gegevensgrenzen

Websoftware staat zelden op zichzelf. Een webshop kan product- en voorraadgegevens uit een ERP-systeem ontvangen, bestellingen naar boekhoudsoftware sturen en klantinformatie via een API beschikbaar maken. Die systemen gebruiken niet altijd dezelfde begrippen of structuur. Een ERP kan bijvoorbeeld meerdere eenheden en magazijnlocaties kennen, terwijl de webshop voor een productpagina vooral één verkoopbare voorraadstatus nodig heeft. De databasekeuze lost dat verschil niet op; daarvoor zijn expliciete mappingregels en afspraken over de bron van waarheid nodig.

Een relationeel model kan externe gegevens normaliseren en koppelingen via sleutels vastleggen. Dat maakt het mogelijk om bijvoorbeeld één intern product aan verschillende externe artikelnummers te verbinden. In een documentmodel kunnen ontvangen brongegevens dicht bij elkaar worden bewaard, wat handig is voor verwerking of onderzoek naar afwijkingen. Maar ongefilterd externe documenten opslaan als interne waarheid maakt de applicatie afhankelijk van het formaat van de leverancier. Een API-wijziging kan dan onverwacht veel onderdelen raken.

Rapportages stellen weer andere vragen dan een online productpagina. Operationele software wil vaak snel één bestelling tonen; een financieel rapport wil omzet groeperen over maanden, btw-tarieven of kanalen. Als zulke analyses steeds complexer worden, kan een apart rapportagemodel nodig zijn, ongeacht de primaire database. Leg vast welke gegevens leidend zijn, hoe wijzigingen worden doorgegeven en hoe fouten opnieuw verwerkt kunnen worden. Zo voorkom je dubbele boekingen, verouderde voorraadcijfers en rapportages die verschillende definities van dezelfde uitkomst gebruiken.

Beheer, indexen en schaalbaarheid in de dagelijkse praktijk

De dagelijkse beheerkosten zitten niet alleen in de licentie of hosting. Teams moeten back-ups kunnen terugzetten, indexen onderhouden, foutieve gegevens opsporen en wijzigingen veilig uitrollen. Relationele databases vragen om aandacht voor schema’s, queryplannen en indexen. Een index op veelgebruikte filters kan zoekopdrachten versnellen, maar maakt schrijven en opslag zwaarder. Te veel indexen zijn dus geen gratis prestatieverbetering. Ook kan een query die aanvankelijk snel is, veranderen wanneer tabellen groeien of de verdeling van waarden verschuift.

Documentdatabases hebben hun eigen aandachtspunten. Indexen moeten aansluiten op de manier waarop documenten worden doorzocht, en grote of sterk geneste documenten kunnen onhandig worden om vaak gedeeltelijk bij te werken. Als dezelfde gegevens in veel documenten zijn gekopieerd, kunnen updates kostbaar worden en tot verschillen leiden. Een documentstructuur die prima werkt voor een kleine collectie kan onder belasting tegen grenzen aanlopen wanneer één document veel gelijktijdige wijzigingen krijgt of een veelgebruikte query geen passende index heeft.

Schaalbaarheid is daarom geen automatisch voordeel van de ene categorie. Meet de verwachte lees- en schrijfbelasting, de grootte van records en de pieken in gebruik. Test ook herstel en migraties: een database die snel werkt maar moeilijk terug te zetten is, vormt een operationeel risico. Houd daarnaast rekening met kennis in het team en de beschikbare monitoring. Een vertrouwde relationele database kan in de praktijk beter schaalbaar zijn dan een documentdatabase die niemand goed kan beheren, en andersom.