Wat is een database? Een gids voor mensen die apps bouwen

Een database is een georganiseerde opslag van informatie waar een app naartoe schrijft en vanaf leest: zijn gebruikers, bestellingen, boekingen, berichten. In tegenstelling tot informatie die alleen in een browsertabblad staat, blijft gegevens in een database bewaard na een refresh of herstart, en ziet iedereen die de app gebruikt dezelfde records. De meeste databases organiseren gegevens in tabellen, vergelijkbaar met bladen in een spreadsheet, maar met strikte regels die de gegevens consistent houden.

Waarom het ertoe doet als je met AI bouwt

De meest voorkomende verrassing bij mensen die met AI bouwen is een app die af lijkt, maar alles vergeet. Je voegt een klant toe, je laadt de pagina opnieuw en hij is weg. Dat betekent meestal dat de app gegevens in het geheugen van de browser bewaarde, niet in een database.

Een database is ook de plek waar veel van je belangrijkste beslissingen worden vastgelegd, of je dat nu doorhebt of niet:

• Wat je vastlegt. Als je de status van een boeking niet opslaat, kun je niet laten zien welke boekingen zijn geannuleerd.
• Hoe dingen samenhangen. Of één klant veel boekingen kan hebben, of één boeking veel diensten, bepaalt de hele app.
• Wie wat mag zien. De meeste privacyfouten gaan over welke records een gebruiker mag lezen.

Je hoeft de database niet zelf te ontwerpen. Maar als je de basis begrijpt, kun je je gegevens duidelijk beschrijven en problemen vroeg opmerken.

Een alledaagse vergelijking

Stel je een goed georganiseerde archiefkast in een klein kantoor voor.

Elke lade bevat één soort ding: één lade voor klanten, één voor afspraken, één voor facturen. Binnen elke lade volgt elk dossier dezelfde indeling, met dezelfde velden ingevuld. Elk dossier heeft een uniek referentienummer, en wanneer een factuur bij een klant hoort, noteert het factuurdossier het klantnummer in plaats van het hele klantdossier te kopiëren.

Dat is een relationele database. De laden zijn tabellen, de dossiers zijn rijen, de velden zijn kolommen, de referentienummers zijn primaire sleutels, en de notities die naar een ander dossier verwijzen zijn refererende sleutels (foreign keys). Een goede kantoormanager handhaaft ook regels (geen afspraak zonder datum, geen twee klanten met hetzelfde nummer), net zoals een database dat doet.

Een uitgewerkt voorbeeld: een boekingsapp voor een kapsalon

Stel dat je een AI vraagt een boekingssite voor een kapsalon te bouwen. Een verstandige database zou vier tabellen hebben.

diensten

medewerkers

klanten

boekingen

Kijk naar de tabel boekingen. Daarin wordt de naam en het telefoonnummer van Lena niet in elke boeking gekopieerd; er staat klant_id = 101. Als Lena haar telefoonnummer wijzigt, verandert het op één plek, en toont elke boeking het nieuwe nummer. Dat is het kernidee van een relationele database: sla elk feit één keer op en verwijs ernaar.

Dezelfde structuur beantwoordt nuttige vragen:

• “Welke tijden zijn vrij voor Omar op vrijdag?” Bekijk Omars boekingen van die dag.
• “Hoeveel heeft kleuren deze maand opgeleverd?” Koppel boekingen aan diensten en tel de prijzen op.
• “Welke klanten hebben de afgelopen 90 dagen niets geboekt?” Vergelijk klanten met hun laatste boeking.

Veelvoorkomende begrippen uitgelegd

Soorten databases

Voor bijna alles wat een oprichter of klein bedrijf als eerste bouwt, is een relationele database de veilige standaardkeuze.

Waar de database in je app zit

Bezoekers praten nooit rechtstreeks met de database. De pagina in hun browser (de frontend) vraagt je server (de backend) om gegevens, meestal via een API. De server controleert wie er vraagt en of die persoon toegang heeft, query’t vervolgens de database en stuurt alleen terug wat die persoon mag zien.

Die tussenstap is belangrijk. Als de browser rechtstreeks met volledige toegang de database kon bevragen, kon iedereen via de ontwikkelaarstools alles lezen.

Veelgemaakte fouten en misverstanden

• Gegevens alleen in de browser bewaren. Browseropslag (zoals localStorage) leeft op één apparaat en in één browser. Dat is prima voor een onthouden filter, niet voor bestellingen.
• Alles in één tabel proppen. Een enkele tabel “boekingen” met de naam, het telefoonnummer en de dienstprijs van de klant in elke rij, raakt snel uit de pas.
• Wachtwoorden als platte tekst opslaan. Wachtwoorden moeten gehasht worden, nooit leesbaar opgeslagen. Zie wat authenticatie is.
• Geen regels op de gegevens. Zonder verplichte velden en uniciteitsregels krijg je boekingen zonder datum en dubbele klanten.
• Vergeten wat er bij verwijderen gebeurt. Bepaal of het verwijderen van een klant ook zijn boekingen verwijdert, ze bewaart, of het blokkeert.
• Productiegegevens gebruiken om te experimenteren. Test riskante wijzigingen eerst ergens veiligs, en houd back-ups bij.
• De spreadsheet voor altijd als database gebruiken. Spreadsheets zijn prima om mee te beginnen, maar ze hebben moeite met veel gelijktijdige gebruikers en rechten. Zie hoe je een spreadsheet in een app verandert.

Wat je aan je AI-appbouwer kunt vragen

• “Sla dit op in een database, niet in de browser. Vertel me welke tabellen je gaat maken.”
• “Laat me het schema zien als een eenvoudige tabel: elke tabel, zijn kolommen en hoe ze aan elkaar gekoppeld zijn.”
• “Een klant kan veel boekingen hebben; elke boeking heeft precies één dienst en één medewerker.”
• “Maak e-mail verplicht en uniek voor klanten.”
• “Voorkom dat twee boekingen voor dezelfde medewerker elkaar overlappen.”
• “Alleen de ingelogde eigenaar kan alle boekingen lezen; klanten zien alleen hun eigen boekingen. Handhaaf dat op de server.”
• “Als ik een dienst verwijder, verwijder dan geen eerdere boekingen; zet de dienst op inactief.”

Databases in Mythex

Als je app gegevens moet opslaan, voegt Mythex een eigen Postgres-database toe aan het project. Je kunt dat in de chat vragen (“sla wachtlijstaanmeldingen op in een database”) of het commando /database gebruiken. Verbindingsgegevens worden automatisch aan je app doorgegeven, en de agent maakt de tabellen aan. De database gaat na vijf minuten inactiviteit slapen en wordt wakker bij het volgende verzoek. Bij gepubliceerd gebruik wordt betaald voor de tijd dat hij wakker was, uit hetzelfde creditsaldo als het bouwen. Hij is beschikbaar op Free en Pro. De databasedocumentatie behandelt de details, en de app-sjablonen bevatten startpunten met data.

Veelgestelde vragen