Als iemand je formulier verstuurt, komen de gegevens ergens terecht. De meeste formuliertools bewaren ze in een database. Je denkt er waarschijnlijk niet over na wat een database is of hoe die is ingedeeld. Dat hoeft ook niet. Je hoeft geen database-expert te zijn. Je moet alleen weten dat het ontwerp van een database bepaalt of je formuliertool snel, betrouwbaar en bruikbaar is.
Dit artikel legt uit wat een database is, waarom het ontwerp ertoe doet voor formulieren en waar je op let als je een formuliertool kiest.
Wat is een database en waarom is het belangrijk
Een database is een geordende opslag voor informatie. Zie het als een archiefkast, maar digitaal en veel beter geordend. Papieren in een archiefkast sorteer je op map, dan op soort en dan in een vaste volgorde, zodat je ze later terugvindt. Een database werkt hetzelfde: je formuliergegevens staan in een vaste structuur, zodat ze snel en betrouwbaar terug te vinden zijn.
Als iemand je formulier verstuurt, komen de gegevens (naam, e-mailadres, bericht en zo meer) in de database. Die database bevat al je inzendingen. De manier waarop de database is ingedeeld bepaalt drie dingen:
Snelheid: Haalt je formuliertool al je inzendingen in één seconde op? Of duurt het minuten? Dat hangt af van het database-ontwerp.
Betrouwbaarheid: Zijn je gegevens veilig? Raak je inzendingen kwijt als er iets kapotgaat? Dat hangt af van het database-ontwerp en van de back-ups.
Bruikbaarheid: Kun je je gegevens exporteren? Delen met andere tools? Zoeken naar specifieke inzendingen? Ook dat hangt af van het database-ontwerp.
Een goed database-ontwerp merk je niet. Alles werkt snel en je denkt er nooit over na. Een slecht ontwerp wordt duidelijk zodra je formuliertool traag is, je geen gegevens kunt exporteren of inzendingen ineens verdwijnen.
Hoe databases formuliergegevens ordenen: tabellen, rijen en velden
Een database bestaat uit tabellen. Zie een tabel als een spreadsheet. Elke rij is een inzending. Elke kolom is een veld uit je formulier.
Voorbeeldtabel voor een contactformulier:
Rij 1: Jane Smith, jane@example.com, Vraag over verkoop, "Ik ben geïnteresseerd in de prijzen", 2026-04-01 14:23:00
Rij 2: John Davis, john@example.com, Technische ondersteuning, "Het formulier wordt niet verstuurd", 2026-04-02 09:15:00
Elke rij is één inzending. Elke kolom is een veld (naam, e-mailadres, soort vraag, bericht, tijdstip van inzending).
Deze eenvoudige structuur werkt prima voor simpele formulieren. Maar de meeste formulieren in de praktijk zijn ingewikkelder.
Meerdere formulieren in dezelfde database
Heeft je website meerdere formulieren (contactformulier, demo-aanvraag, aanmelding voor de nieuwsbrief), dan kan elk formulier een eigen tabel hebben. Of de database heeft één grote tabel met inzendingen en een extra kolom die aangeeft van welk formulier de inzending komt.
Optie 1: aparte tabellen. Elk formulier krijgt een eigen tabel. Inzendingen van het contactformulier gaan naar de tabel "contact_form_submissions". Demo-aanvragen gaan naar "demo_request_submissions". Dit is overzichtelijker en sneller, omdat elke tabel kleiner is en past bij de opbouw van dat formulier.
Optie 2: één tabel. Alle inzendingen gaan naar één tabel "submissions" met een kolom "form_type". Dit is makkelijker te beheren als je veel formulieren hebt, maar de tabel groeit snel en zoekopdrachten worden trager.
De meeste goed ontworpen formuliertools kiezen optie 1 (aparte tabellen). Zo blijft alles overzichtelijk en snel naarmate je meer formulieren verwerkt.
Omgaan met complexe veldtypen
Niet alle formuliervelden zijn gewone tekst. Wat gebeurt er als iemand een bestand uploadt, meerdere selectievakjes aanvinkt of gegevens invult die uit meerdere delen bestaan?
Bestanden uploaden
Bestanden staan meestal niet in de database zelf. Databases zijn daar slecht in. Het bestand staat op een bestandsserver (of in cloudopslag zoals AWS S3) en de database bewaart alleen een verwijzing naar dat bestand (een link of een uniek ID).
Vraag je de database om een inzending met een bestand, dan geeft de database de verwijzing terug en weet je systeem hoe het het echte bestand ophaalt van de bestandsserver.
Meerdere selectievakjes
Vraagt je formulier "Waar ben je in geïnteresseerd?" met opties als "Productfuncties", "Prijzen" en "Demo's", en vinkt iemand meerdere vakjes aan, dan moet de database meerdere waarden in één veld bewaren.
Sommige databases slaan dit op als een lijst met komma's: "Productfuncties, Prijzen, Demo's". Andere maken een aparte tabel voor de gekozen opties, met één rij per optie. De tweede aanpak is technisch netter, maar ook ingewikkelder.
Samengestelde gegevens (zoals een adres)
Een adresveld kan bestaan uit straat, huisnummer, postcode en plaats. Sommige databases bewaren dit als één lange tekst ("Kerkstraat 123, 1011 AB Amsterdam"). Andere maken voor elk onderdeel een aparte kolom. Aparte kolommen zijn beter als je ooit wilt zoeken op plaats of filteren op postcode.
Indexeren: zoekopdrachten snel maken
Als je tabel met inzendingen groeit tot duizenden of miljoenen rijen, worden zoekopdrachten trager. Alle inzendingen van een bepaalde datum vinden duurt langer. Filteren op e-mailadres ook.
Databases lossen dit op met indexen. Een index is als een gesorteerde lijst. Heeft de database het veld "e-mailadres" geïndexeerd, dan vindt ze "jane@example.com" meteen, in plaats van elke rij in de tabel te controleren.
Goede formuliertools maken indexen aan op velden waarop mensen vaak zoeken (datum van inzending, formuliernaam, e-mailadres). Slechte tools doen dat niet, en zoekopdrachten worden erg traag als je veel inzendingen hebt.
Veel volume aankunnen: schaalbaarheid
Wat gebeurt er als je formulier populair wordt en honderden inzendingen per uur krijgt?
Een slecht ontworpen database kan vertragen of crashen. Een goed ontworpen database schaalt mee. Schalen betekent dat de database steeds meer volume aankan zonder dat de prestaties dalen.
Zo doen databases dat:
Sharding: inzendingen verdelen over meerdere databaseservers. Inzendingen van januari tot en met maart gaan naar de ene server, die van april tot en met juni naar een andere. Zo wordt de belasting verdeeld.
Replicatie: kopieën van de database maken, zodat leesverzoeken (mensen die inzendingen bekijken) worden verdeeld. De hoofddatabase verwerkt het schrijven (nieuwe inzendingen) en de kopieën verwerken het lezen.
Caching: veelgevraagde gegevens in het geheugen bewaren (veel sneller dan opslag op schijf). Vragen 100 mensen dezelfde inzending op, dan komen het tweede verzoek en alle verdere verzoeken uit de cache in plaats van uit de database.
Connection pooling: het aantal gelijktijdige databaseverbindingen beperken, zodat de database niet overbelast raakt door te veel verzoeken tegelijk.
Een formuliertool die weet dat hij veel volume krijgt (zoals een tool met 10.000 bedrijven als gebruiker) ontwerpt hierop. Een tool die weinig volume verwacht doet dat vaak niet, en dan merk je het probleem pas als je zelf veel volume hebt.
Gegevens bewaren en archiveren
Databases hebben een opslaglimiet (meestal gemeten in gigabytes of terabytes). Na miljoenen inzendingen wordt je database erg groot. Grote databases zijn trager en duurder om te onderhouden.
Goede formuliertools archiveren. Oude inzendingen (bijvoorbeeld van meer dan twee jaar geleden) gaan naar goedkopere archiefopslag of worden helemaal verwijderd. Je actieve database bevat dan alleen recente inzendingen, zodat zoekopdrachten snel blijven.
Zonder archivering wordt je database uiteindelijk een traag en duur probleem.
Back-upstrategie: bescherming tegen verlies
Elke database heeft back-ups nodig. Valt de hoofddatabase uit (hardwarecrash, beschadigde gegevens, aanval), dan heb je een back-up om op terug te vallen.
Goede back-uppraktijken:
Meerdere back-ups (minstens één, liefst drie). Back-ups op verschillende locaties (vat je hoofdserver vlam, dan helpt een back-up op dezelfde plek niet). Regelmatig testen (zet af en toe een back-up terug om te controleren of die werkt). Automatische back-ups (elke dag of elk uur, niet met de hand).
Vraag je formuliertool of ze een back-up van je gegevens maken en hoe vaak. Zeggen ze "wij maken geen back-ups" of "back-ups gebeuren handmatig, eens per maand", dan is dat een risico. Je wilt dagelijkse of nog vaker automatische back-ups.
Formuliergegevens opvragen: zo kom je bij je inzendingen
Vraag je je formulierinzendingen op (via een dashboard of API), dan doet de formuliertool een zoekopdracht in de database. Een goed ontworpen database laat je efficiënt zoeken:
Eenvoudige zoekopdrachten: "Toon alle inzendingen van dit formulier" moet direct gaan.
Gefilterde zoekopdrachten: "Toon alle inzendingen met dit e-mailadres" moet snel gaan.
Zoekopdrachten op een bereik: "Toon alle inzendingen van 1 maart tot en met 31 maart" moet snel gaan.
Complexe zoekopdrachten: "Toon alle inzendingen waarbij inquiry_type = 'Sales' EN country = 'USA' EN submission_date > 2026-03-01" moet redelijk snel gaan.
In een slecht ontworpen database zijn complexe zoekopdrachten erg traag. Daarom zijn de dashboards van sommige formuliertools stroperig: ze voeren inefficiënte zoekopdrachten uit op slecht ontworpen databases.
Consistente en betrouwbare gegevens
Een database moet garanderen dat gegevens kloppen en consistent zijn. Dat betekent:
Geen dubbele inzendingen: wordt hetzelfde formulier twee keer verstuurd, dan moet de database dubbele inzendingen voorkomen (of ze minstens herkennen).
Referentiële integriteit: verwijst een inzending naar andere gegevens (zoals een gebruikers-ID), dan moet dat gebruikers-ID echt bestaan.
Controle op gegevenstype: een e-mailveld accepteert alleen geldige e-mailadressen. Een getalveld accepteert alleen getallen.
Geen verloren gegevens: mislukt een schrijfactie halverwege, dan draait de database alles volledig terug in plaats van half opgeslagen gegevens te bewaren.
Deze garanties komen voort uit het database-ontwerp. Een goed schema dwingt ze automatisch af. Bij een slecht schema moet de code van de formuliertool dat doen, en dat gaat vaker mis.
Zo slaat WEMASY formulierinzendingen op
WEMASY gebruikt een relationeel database-ontwerp waarin elk formulier een eigen tabel voor inzendingen heeft, afgestemd op de opbouw van dat formulier. Inzendingen zijn geïndexeerd op datum en formulier-ID, zodat ze snel op te halen zijn. De database maakt automatisch dagelijks een back-up en houdt reserve-kopieën bij, zodat gegevens nooit verloren gaan. Groeit je aantal inzendingen, dan schaalt WEMASY automatisch mee. Bij archivering gaan inzendingen die ouder zijn dan twee jaar naar koude opslag, zodat je actieve database snel en soepel blijft.
Voor technische details over hoe WEMASY je formuliergegevens opslaat, kijk je in het dashboard van je account of op de prijspagina, waar je ziet welke functies voor gegevensbeheer in je abonnement zitten.