Een database toevoegen aan uw app (zonder later data te verliezen)

Om een database aan uw app toe te voegen, kiest u een beheerde relationele database (Postgres is de gebruikelijke standaard), bewaart u de verbindingsstring in een geheim op de server, maakt u één tabel per soort ding dat uw app opslaat, en laat u uw backend — nooit de browser — die database lezen en schrijven. Als u met een AI-app-builder werkt, kunt u meestal gewoon zeggen „sla dit op in een database“ en zet de agent de tabellen en code op. Uw taak is de gegevens duidelijk beschrijven en controleren of ze echt blijven bestaan.

Deze gids behandelt wanneer u een database nodig hebt, de belangrijkste opties, hoe u uw gegevens beschrijft en de fouten die verloren of gelekte data veroorzaken.

Wanneer uw app een database nodig heeft

U hebt een database nodig wanneer uw app iets moet onthouden nadat de pagina is gesloten, of gegevens tussen mensen moet delen. Typische signalen:

Bezoekers sturen iets in: een formulier, een aanmelding, een boeking, een bestelling
Gebruikers hebben accounts met hun eigen opgeslagen inhoud
Een beheerder moet zien of bewerken wat anderen hebben gemaakt
U wilt rapportages of tellingen over tijd

Voor een statische site waar iedereen dezelfde inhoud ziet, zoals een portfolio of een eenvoudige landingspagina, hebt u er geen nodig. Weet u niet precies wat een database is? Lees dan eerst wat is een database.

Uw opties

Optie	Wat het is	Geschikt voor	Nadelen
Ingebouwde database van uw app-builder	Een database die voor uw project is aangemaakt en gekoppeld	De meeste apps die met een AI-builder zijn gemaakt	Gebonden aan het hostingplatform; export en back-ups hangen af van het platform
Beheerde Postgres of MySQL	Een gehoste relationele database die u afzonderlijk aanvraagt	Apps die u zelf host, of die meerdere diensten delen	U beheert sleutels, verbindingslimieten en abonnementen
Backend-as-a-service	Database plus authenticatie, opslag en API's in één product	Frontend-zware apps die kant-en-klare inlog willen	Meer leverancier-specifieke concepten om te leren
Documentdatabase (NoSQL)	Slaat flexibele, JSON-achtige documenten op	Zeer onregelmatige gegevens	Relaties en rapportages zijn lastiger
Een spreadsheet als database	Google Sheets of vergelijkbaar via een API	Kleine interne tools, prototypes	Traag, geen echte beperkingen, breekt bij gelijktijdig bewerken

Voor de meeste kleine en middelgrote webapps is een relationele database zoals Postgres de juiste standaard. Ze is sterk in relaties (een klant heeft veel bestellingen), houdt gegevens consistent en laat u later vragen beantwoorden met SQL. Zie wat is Postgres voor een uitleg in begrijpelijke taal.

Beschrijf uw gegevens vóór het bouwen

Het nuttigste wat u kunt doen, is opschrijven welke dingen uw app opslaat en hoe ze met elkaar verbonden zijn. U hebt geen databasejargon nodig. Voor een boekingsapp:

Klanten: naam, e-mail, telefoonnummer
Diensten: naam, duur, prijs
Boekingen: welke klant, welke dienst, starttijd, status (in behandeling, bevestigd, geannuleerd)

Dat zijn drie tabellen. „Welke klant“ en „welke dienst“ worden koppelingen (vreemde sleutels) tussen de tabellen. Dit vroeg goed krijgen is veel belangrijker dan welke technologie u kiest, omdat het veranderen van de structuur van gegevens die al echte rijen bevatten, moeilijker is dan het aanpassen van een paginaindeling.

Enkele vuistregels:

Eén tabel per soort ding. Plaats bestellingen niet in een tekstkolom van de klant.
Geef elke rij een ID en een aanmaaktijd. U wilt die later allebei.
Gebruik juiste typen. Datums als datums, geld als hele centen of een decimaal type, niet als tekst.
Markeer verplichte velden als verplicht. Laat de database slechte gegevens weigeren, niet alleen het formulier.

Voorbeeldprompts

Begin met één functie tegelijk in plaats van in één keer een hele structuur te dumpen:

Voeg een database toe aan deze app. Maak een tabel boekingen met klantnaam, e-mail, dienst, starttijd en status (in behandeling, bevestigd, geannuleerd; standaard in behandeling). Sla inzendingen van het boekingsformulier erin op, toon een succesbericht en voeg een beheerderspagina toe die boekingen van nieuw naar oud toont.

Breid het daarna uit:

Voeg een tabel diensten toe (naam, duur in minuten, prijs in centen). Vervang het vrije tekstveld voor de dienst bij boekingen door een koppeling naar diensten, en migreer bestaande boekingen zonder ze te verwijderen.

En maak het strakker:

Zorg dat alle database-lees- en schrijfacties op de server gebeuren. De browser mag de verbindingsstring van de database nooit ontvangen. Valideer het e-mailadres en de starttijd op de server voordat je iets invoegt.

Stap voor stap

Maak een lijst van uw gegevens zoals hierboven: dingen, velden, koppelingen tussen de dingen.
Maak de database aan. In een AI-builder vraagt u er in de chat om. Elders maakt u een beheerde Postgres-instantie aan en kopieert u de verbindingsstring.
Bewaar de verbindingsstring als geheim (een omgevingsvariabele op de server), nooit in de code. Zie omgevingsvariabelen en geheimen.
Maak de tabellen. Gebruik migraties — versiegebonden scripts die het schema wijzigen — zodat wijzigingen herhaalbaar en terug te draaien zijn.
Bouw de serverroutes die rijen aanmaken, lezen, bijwerken en verwijderen (CRUD). De browser roept deze routes aan; hij praat nooit rechtstreeks met de database.
Koppel de interface aan die routes: formulieren die opslaan, lijsten die laden, lege staten als er nog niets is.
Test of de gegevens blijven bestaan. Stuur iets in, herlaad de pagina, open hem in een andere browser. Als de gegevens er niet zijn, zijn ze niet in de database opgeslagen.
Controleer de toegang. Log in als tweede gebruiker en controleer of u de gegevens van de eerste gebruiker niet kunt zien of bewerken.
Publiceer en test opnieuw op de live URL, omdat de gepubliceerde app een andere verbinding kan gebruiken dan uw preview.

Veelgemaakte fouten

Opslaan in de browser en denken dat het is opgeslagen. localStorage lijkt te werken totdat iemand de app op een ander apparaat opent. Test altijd in een tweede browser.
De verbindingsstring in frontendcode zetten. Iedereen kan frontendcode lezen. Dat geeft hen uw hele database.
Geen toegangscontroles. „Toon mijn bestellingen“ moet op de server filteren op de ingelogde gebruiker, niet in de interface. Dit is het meest voorkomende beveiligingsprobleem in met AI gebouwde apps; onze beveiligingschecklist behandelt het.
Destructieve schemawijzigingen. Vragen om de tabel te „hernoemen“ of de „structuur te wijzigen“ kan leiden tot verwijderen en opnieuw aanmaken. Als er echte data bestaat, zeg dan „migreer de bestaande rijen, verwijder niets“.
Bestanden in de database opslaan. Afbeeldingen en pdf's horen in bestandsopslag, met alleen hun URL of sleutel in een tabel. Zie hoe u bestandsuploads toevoegt.
Geen back-ups. Weet hoe uw platform back-ups maakt en hoe u kunt herstellen voordat u klanten hebt.

Checklist

Elk soort ding heeft een eigen tabel met een ID en aanmaaktijd
Verplichte velden en typen worden door de database afgedwongen
De verbindingsstring staat alleen in geheimen op de server
Alle lees- en schrijfacties lopen via serverroutes
Elke gebruiker kan alleen de eigen rijen lezen en wijzigen
Gegevens blijven behouden na een herlaad en zijn zichtbaar in een andere browser
Schemawijzigingen gebruiken migraties en behouden bestaande rijen
U weet hoe back-ups en herstel werken
De live app is getest na publicatie

Een database toevoegen in Mythex

Op Mythex kan elk project een eigen, speciaal voor het project bestemde Postgres-database krijgen, zowel op Free als op Pro. U hoeft meestal geen aparte knop „koppelen“ te gebruiken: vraag het in de chat („sla wachtlijst-e-mails op in een database“) of typ /database, en de verbindingsgegevens worden in de werkruimte en uw gepubliceerde app ingevoegd. Bij de projectinstellingen ziet u of een database actief is.

De database gaat na 5 minuten inactiviteit slapen en wordt wakker bij het volgende verzoek. Gepubliceerd gebruik wordt gefactureerd voor de tijd dat de database daadwerkelijk wakker was, uit hetzelfde creditsaldo dat u voor het bouwen gebruikt. Als u een database toevoegt nadat u al hebt gepubliceerd, publiceer dan opnieuw zodat de live app die oppikt.

Zie Database en het recept Een CRUD-app bouwen in de documentatie. Voor de inlogkant van gegevens per gebruiker leest u hoe u inloggen aan uw app toevoegt.

Veelgestelde vragen

Heb ik een database nodig voor mijn app?

U hebt er een nodig zodra uw app iets moet onthouden nadat de pagina is gesloten, of gegevens moet delen tussen gebruikers: aanmeldingen, bestellingen, boekingen, berichten of instellingen. Een statische website die iedereen dezelfde inhoud toont, heeft geen database nodig.

Welke database gebruik ik voor een kleine webapp?

Een relationele database zoals Postgres is voor de meeste kleine webapps een veilige standaardkeuze. Het verwerkt gebruikers, bestellingen, relaties en rapportages goed, wordt breed ondersteund en op kleine schaal loopt u er zelden tegenaan.

Kan ik gegevens in de browser opslaan in plaats van in een database?

Browseropslag zoals localStorage bestaat alleen op één apparaat, in één browser, en de gebruiker kan die op elk moment wissen. Het is prima voor voorkeuren zoals een themakeuze, maar niet voor iets wat u of andere gebruikers later moeten zien.

Heeft Mythex een database?

Ja. Een Mythex-project kan op Free en Pro een eigen, speciaal voor het project bestemde Postgres-database krijgen. U vraagt er om in de chat of typt /database, en de verbindingsgegevens worden automatisch ingevoegd. Het gebruik wordt betaald uit hetzelfde creditsaldo als het bouwen.