Een relationele database slaat data op in tabellen met rijen en kolommen, waarbij tabellen via gedeelde sleutels aan elkaar gekoppeld zijn. Een tabel “klanten” hangt samen met een tabel “bestellingen”, zodat elke bestelling weet bij welke klant hij hoort, zonder de naam en het adres van die klant in elke rij te herhalen.
Zie het als een goed geordende archiefkast met kruisverwijzingen. In de ene lade zitten klantkaarten, in de andere facturen, en elke factuur noteert simpelweg het klantnummer in plaats van het hele adres te kopiëren. Wijzig het adres één keer op de klantkaart en elke factuur wijst nog steeds naar de juiste plek. Daarom passen relationele databases zo natuurlijk bij SQL, de taal waarmee je ze bevraagt, en houdt goede databasenormalisatie de structuur netjes en vrij van dubbele gegevens.
Dit model draait al decennia serieuze zakelijke software, omdat het betrouwbaar is en data consistent houdt. Als die strakke structuur in de weg zit, grijpen teams soms naar een NoSQL-optie.
Een groot deel van die betrouwbaarheid komt van transacties. Als iemand een product koopt, moet het systeem voorraad afboeken en de bestelling vastleggen als één ondeelbare actie; óf allebei gebeurt, óf niets, zodat je nooit iets verkoopt dat je niet meer hebt. Die alles-of-niets-garantie is precies waarom banken, webshops en boekhoudtools op relationele databases leunen. De prijs is dat de tabelstructuur lastig te wijzigen is zodra de data zich heeft opgestapeld, en daarom blijven de ontwerpkeuzes van dag één vaak jaren hangen. Een kolom toevoegen kan meestal nog wel, maar twee tabellen die verkeerd zijn opgesplitst weer samenvoegen is een flinke klus zodra er duizenden rijen in zitten.
Bij TopDevs ontwerpen we de tabelstructuur van de relationele database van een klant zorgvuldig vooraf, want een schoon datamodel houdt een applicatie jaren later nog onderhoudbaar.
