Wat je met je database doet voordat je live gaat

Wat is er anders aan een database die live staat?

De inhoud is van iemand anders. Zolang jij de enige bent die gegevens invoert, is een database een kladblok: gaat het mis, dan begin je opnieuw en niemand merkt het. Zodra een vreemde iets invoert, een account, een bestelling, een bericht, is het zijn gegeven geworden en jouw verantwoordelijkheid. Kwijt is dan echt kwijt, en het is niet jouw verlies maar het zijne.

Daar komt bij dat een database die live staat bereikbaar is vanaf het internet, en niet alleen vanuit je bouwtool. De instellingen die in een proefomgeving prima waren, iedereen mag lezen, het wachtwoord staat in de code, de back-up staat uit omdat er niets te bewaren was, zijn op een live systeem precies de instellingen die je niet wilt.

En hij groeit. Een proefdatabase heeft tien rijen. Een live database heeft er na een jaar duizenden, en daar zit dan ook administratie in: facturen, betalingen, gegevens waar een bewaarplicht op rust. Wat je nu inricht, bepaalt hoe makkelijk dat over een jaar nog te overzien is.

• Van kladblok naar bewaarplaats op het moment dat een vreemde iets invoert.
• Bereikbaar vanaf het internet, met de instellingen van een proefomgeving.
• Hij groeit, en er komt administratie in.

Van wie is de database, en kun je ermee weg?

De database die je bouwtool aanmaakte, staat vaak op een account van de tool, of op een account dat via de tool is aangemaakt en waar jij niet rechtstreeks bij kunt. Controleer dat als eerste. Kun je zelf inloggen bij de databasedienst, los van de tool, en zie je daar je gegevens? Dan is hij van jou. Zo niet, dan maak je zelf een account aan bij een databasedienst, zet je een lege database klaar en laat je de tool daarnaar wijzen. De documentatie van je tool beschrijft hoe.

Kies een dienst waar je met een gewone export weer weg kunt: een bestand dat een andere dienst kan inlezen zonder hulp van de eerste. De meeste bekende diensten bieden dat, en het is de vraag die je stelt voordat je kiest, niet erna. Een database waar je niet uit kunt, is geen database maar een huurcontract.

Schrijf op waar de database staat, onder welk account, en waar de inloggegevens bewaard zijn. Dat lijkt overdreven tot het moment dat je het na drie maanden niet meer weet.

• Kun je zonder de tool inloggen bij de databasedienst en je gegevens zien.
• Kies een dienst met een gewone export; vraag dat vooraf.
• Schrijf op waar hij staat en onder welk account.

Welke back-up moet je echt maken?

De back-up die je een keer hebt teruggezet. Een back-up die je nooit hebt teruggezet is een hoop; je weet niet of hij compleet is, of hij leesbaar is, en of jij weet hoe het moet op het moment dat je in paniek bent. Daarom is de belangrijkste handeling in dit artikel niet de back-up maken maar hem terugzetten, op een lege database, en controleren dat alles er staat.

Doe dat nu, met de tien rijen uit je proefomgeving, want dan kost een fout niets. Maak een back-up via de dienst zelf of via een export, maak een tweede lege database, zet de back-up daarop terug, en kijk. Werkt het, dan weet je twee dingen: dat het kan, en hoe lang het duurt. Dat tweede is later net zo belangrijk als het eerste.

Zet daarna een automatische back-up aan, dagelijks, met een bewaartermijn van minimaal een paar weken, zodat je ook terug kunt naar een punt vóór een fout die je pas na een week ontdekte. De meeste diensten hebben dat als instelling; bij sommige zit het alleen in een betaald plan, en dan is dat plan het geld waard.

• Een back-up is pas een back-up als je hem een keer hebt teruggezet.
• Oefen het nu, met proefgegevens, op een lege database.
• Automatisch, dagelijks, een paar weken bewaren.

Wie mag erin, en hoe beperk je dat?

Een databasedienst kent meestal twee soorten toegang: de sleutel waarmee je project zelf leest en schrijft, en de regels die bepalen wat een bezoeker via je project mag zien. De eerste hoort niet in je code te staan maar in de instellingen van je host, als omgevingsvariabele. De tweede is waar de meeste fouten zitten: een AI die snel wil bouwen zet de regels graag op alles mag, omdat het dan werkt.

Controleer dus, per tabel, wie mag lezen en wie mag schrijven. Een gebruiker mag zijn eigen gegevens zien, niet die van een ander. Een bezoeker zonder account mag misschien een openbare lijst zien, maar niets aanpassen. Hoe dat precies heet, verschilt per dienst; de documentatie van je dienst heeft er een eigen hoofdstuk over, en de gezondheidscheck op deze site heeft er een punt voor.

Test het van buiten. Log in als een tweede testaccount en probeer de gegevens van het eerste te openen. Lukt dat, dan is er werk. Lukt het niet, dan heb je iets gecontroleerd wat de meeste makers aannemen.

• De sleutel van je project: in de instellingen van de host, niet in de code.
• De regels per tabel: wie leest, wie schrijft. Nooit alles mag.
• Test het met een tweede account, van buiten.

Wat sla je nooit op?

Wachtwoorden in leesbare vorm. Elke serieuze inlogdienst bewaart een onleesbare afgeleide, en als je bouwtool een eigen inlogsysteem heeft gemaakt, controleer dan dat het dat ook doet. Volledige betaalgegevens: die laat je bij een betaaldienst en je bewaart hoogstens een verwijzing. Kopieën van identiteitsbewijzen, tenzij een wet je daartoe verplicht. En alles wat je niet nodig hebt: elk gegeven dat je bewaart, moet je ook beschermen, en het goedkoopste gegeven is het gegeven dat je niet hebt.

Bedenk ook wat je bewaart over mensen die niets invoeren. Bezoekersgegevens, adressen van apparaten, logboeken: het is verleidelijk om alles te bewaren omdat het kan. Zodra je een e-mailadres of iets vergelijkbaars bewaart, heb je een privacyverklaring nodig die zegt wat je bewaart en waarom, en dat moet je dan ook echt zo doen.

Een goede vraag bij elke kolom: als dit morgen op straat ligt, wat is dan de schade? Is het antwoord groot, dan sla je het niet op of je versleutelt het.

• Geen leesbare wachtwoorden, geen betaalgegevens, geen identiteitsbewijzen.
• Niets wat je niet nodig hebt.
• De vraag per kolom: wat is de schade als dit op straat ligt.

Hoe lang bewaar je wat, en wanneer gooi je weg?

Dat hangt af van wat het is. Gegevens die bij je administratie horen, zoals facturen en betalingen, vallen onder een bewaarplicht van zeven jaar, en voor onroerende zaken tien; de Belastingdienst beschrijft welke gegevens dat zijn. Die gooi je dus niet weg, ook niet als een klant dat vraagt, en dat zeg je dan ook in je privacyverklaring.

Voor de rest geldt het omgekeerde: bewaar niet langer dan nodig. Een account dat een jaar niet gebruikt is, logboeken van drie maanden oud, een bestelling die is afgehandeld en waarvan de factuur elders bewaard wordt: daar mag een opruimregel voor bestaan. Beter nog, die regel bestaat vanaf het begin, want opruimen in een database met vijf jaar geschiedenis is werk dat niemand meer durft te doen.

Houd de twee soorten uit elkaar, in aparte tabellen als het kan. Dan weet je bij het opruimen precies wat mag en wat moet blijven.

• Administratie: zeven jaar, onroerende zaken tien; dat is de wet.
• De rest: niet langer dan nodig, met een opruimregel vanaf dag één.
• Twee soorten, twee plekken.

In welke volgorde regel je het?

Eerst eigendom: kun je zelf bij de database, los van de tool, en kun je eruit met een export. Dan de back-up: maken, terugzetten op een leeg systeem, automatisch aanzetten. Dan toegang: de sleutel uit de code, de regels per tabel, de test met een tweede account. Dan de inhoud: wat je niet opslaat, wat je hoe lang bewaart. Dat is een middag voor een klein project, en het is de middag die het verschil maakt tussen een prototype en iets wat je aan een vreemde durft te geven.

Doe het voordat er echte gegevens in staan. Elke stap is met tien proefrijen een oefening en met duizend echte rijen een operatie. Wie de klif een keer heeft gezien, weet dat dit de stap is die het vaakst wordt overgeslagen en het hardst terugkomt.

En als het klaar is: schrijf in het bestand bij je project op waar de database staat, hoe je een back-up terugzet en wat de regels zijn. Voor jou, over een half jaar.

• Eigendom, back-up, toegang, inhoud. In die volgorde.
• Met proefgegevens, voordat er echte in staan.
• Opschrijven, voor jezelf later.

Bronnen

Nagelopen op 5 september 2026. De bewaartermijnen komen van de Belastingdienst; de rest is werkwijze, en de documentatie van je databasedienst gaat voor op dit artikel.

• Belastingdienst, hoe lang moet u uw administratie bewaren

Verder lezen

Drie plekken die hierop aansluiten.