Was ist eine Datenbank? Ein Leitfaden für Menschen, die Apps bauen
Eine Datenbank ist ein strukturierter Speicher für Informationen, in den eine App schreibt und aus dem sie liest: ihre Nutzer, Bestellungen, Buchungen, Nachrichten. Anders als Informationen, die nur in einem Browser-Tab liegen, bleiben Daten in einer Datenbank nach einem Neuladen oder Neustart erhalten, und alle, die die App nutzen, sehen dieselben Datensätze. Die meisten Datenbanken ordnen Daten in Tabellen, ähnlich wie Blätter in einer Tabellenkalkulation, aber mit strengen Regeln, die die Daten konsistent halten.
Warum das beim Bauen mit KI wichtig ist
Die häufigste Überraschung beim Bauen mit KI ist eine App, die fertig aussieht, aber alles vergisst. Du legst eine Kundin an, lädst die Seite neu, und sie ist weg. Das heißt meist, dass die App Daten im Arbeitsspeicher des Browsers hielt und nicht in einer Datenbank.
Eine Datenbank ist außerdem der Ort, an dem viele deiner wichtigsten Entscheidungen festgehalten werden, ob du es merkst oder nicht:
- Was du erfasst. Speicherst du den Status einer Buchung nicht, kannst du nicht zeigen, welche Buchungen storniert wurden.
- Wie Dinge zusammenhängen. Ob eine Kundin viele Buchungen haben kann oder eine Buchung viele Leistungen, prägt die ganze App.
- Wer was sieht. Die meisten Datenschutzfehler betreffen die Frage, welche Datensätze ein Nutzer lesen darf.
Du musst die Datenbank nicht selbst entwerfen. Doch wer die Grundlagen versteht, kann seine Daten klar beschreiben und Probleme früh erkennen.
Ein Alltagsvergleich
Stell dir einen gut geführten Aktenschrank in einem kleinen Büro vor.
Jede Schublade enthält eine Art von Dingen: eine für Kundschaft, eine für Termine, eine für Rechnungen. In jeder Schublade folgt jede Mappe demselben Format mit denselben ausgefüllten Feldern. Jede Mappe hat eine eindeutige Nummer, und wenn eine Rechnung zu einer Kundin gehört, notiert die Rechnungsmappe deren Nummer, statt die ganze Kundenakte zu kopieren.
Das ist eine relationale Datenbank. Die Schubladen sind Tabellen, die Mappen sind Zeilen, die Felder sind Spalten, die Nummern sind Primärschlüssel, und die Notizen, die auf eine andere Mappe verweisen, sind Fremdschlüssel. Eine gute Büroleitung setzt außerdem Regeln durch, etwa keinen Termin ohne Datum und keine zwei Kunden mit derselben Nummer, genau wie eine Datenbank.
Ein Beispiel: eine Buchungs-App für einen Friseursalon
Nehmen wir an, du bittest eine KI, eine Buchungsseite für einen Friseursalon zu bauen. Eine sinnvolle Datenbank hätte vier Tabellen.
services
| id | name | dauer_minuten | preis |
|---|---|---|---|
| 1 | Haarschnitt | 45 | 40,00 |
| 2 | Färben | 90 | 95,00 |
staff
| id | name | |
|---|---|---|
| 1 | Sara | sara@example.com |
| 2 | Omar | omar@example.com |
customers
| id | name | telefon | |
|---|---|---|---|
| 101 | Lena Park | lena@example.com | 555-0100 |
bookings
| id | customer_id | service_id | staff_id | starts_at | status |
|---|---|---|---|---|---|
| 5001 | 101 | 1 | 2 | 2026-10-03 14:00 | bestätigt |
Sieh dir die Tabelle bookings an. Sie kopiert Lenas Namen und Telefonnummer nicht in jede Buchung, sondern speichert customer_id = 101. Ändert Lena ihre Telefonnummer, wird sie an einer einzigen Stelle geändert, und jede Buchung zeigt die neue. Das ist die Kernidee einer relationalen Datenbank: Jeden Fakt einmal speichern und darauf verlinken.
Dieselbe Struktur beantwortet nützliche Fragen:
- „Welche Termine sind am Freitag bei Omar frei?“ Schau dir Omars Buchungen an diesem Tag an.
- „Wie viel haben Färbetermine diesen Monat eingebracht?“ Verbinde Buchungen mit Leistungen und addiere die Preise.
- „Welche Kundinnen haben seit 90 Tagen nicht gebucht?“ Vergleiche Kundinnen mit ihrer letzten Buchung.
Wichtige Begriffe erklärt
| Begriff | Bedeutung |
|---|---|
| Tabelle | Eine Sammlung einer Art von Datensätzen, etwa Kundinnen oder Buchungen. |
| Zeile (Datensatz) | Ein Element in einer Tabelle, etwa eine Kundin oder eine Buchung. |
| Spalte (Feld) | Eine Information, die jede Zeile hat, etwa E-Mail oder Preis. |
| Primärschlüssel | Eine eindeutige ID für jede Zeile, meist eine Zahl oder eine zufällige Zeichenkette. |
| Fremdschlüssel | Eine Spalte, die auf eine Zeile in einer anderen Tabelle zeigt, etwa customer_id in bookings. |
| Schema | Der Gesamtentwurf: welche Tabellen existieren, ihre Spalten und wie sie verknüpft sind. |
| Abfrage (Query) | Eine Anfrage, Daten zu lesen oder zu ändern, etwa „alle Buchungen für morgen“. |
| SQL | Structured Query Language, die Standardsprache für relationale Datenbanken. |
| Migration | Eine gespeicherte, wiederholbare Änderung am Schema, etwa das Hinzufügen einer Spalte. |
| Index | Eine Nachschlagestruktur, die Suchen in einer Spalte beschleunigt, wie das Stichwortverzeichnis eines Buchs. |
| CRUD | Create, Read, Update, Delete: die vier Grundoperationen, die Apps mit Daten ausführen. |
| Backup | Eine Kopie der Daten, die du wiederherstellen kannst, falls etwas schiefgeht. |
Arten von Datenbanken
| Art | Wie Daten gespeichert werden | Beispiele | Geeignet für |
|---|---|---|---|
| Relational (SQL) | Tabellen mit festen Spalten und Verknüpfungen | Postgres, MySQL, SQLite | Die meisten Geschäfts-Apps: Buchungen, Shops, CRMs, SaaS |
| Dokument (NoSQL) | Flexible JSON-ähnliche Dokumente | MongoDB, Firestore | Daten, deren Form von Datensatz zu Datensatz stark variiert |
| Schlüssel-Wert | Ein Wert unter einem Schlüssel | Redis | Caching, kurzlebige Daten wie Sitzungen |
Für fast alles, was Gründer oder kleine Unternehmen zuerst bauen, ist eine relationale Datenbank der sichere Standard.
Wo die Datenbank in deiner App sitzt
Besucher sprechen nie direkt mit der Datenbank. Die Seite in ihrem Browser (das Frontend) fragt deinen Server (das Backend) nach Daten, meist über eine API. Der Server prüft, wer fragt und ob die Person berechtigt ist, fragt dann die Datenbank ab und schickt nur zurück, was diese Person sehen darf.
Dieser Zwischenschritt ist wichtig. Könnte der Browser die Datenbank direkt mit vollem Zugriff abfragen, könnte jeder die Entwicklertools öffnen und alles lesen.
Häufige Fehler und Missverständnisse
- Daten nur im Browser speichern. Browser-Speicher (etwa localStorage) lebt auf einem Gerät und in einem Browser. Er ist gut für einen gemerkten Filter, nicht für Bestellungen.
- Alles in eine Tabelle stopfen. Eine einzige Tabelle „bookings“, in die Name, Telefon und Leistungspreis der Kundin in jede Zeile kopiert werden, gerät schnell aus dem Takt.
- Passwörter im Klartext speichern. Passwörter sollten gehasht und niemals lesbar gespeichert werden. Siehe was Authentifizierung ist.
- Keine Regeln für die Daten. Ohne Pflichtfelder und Eindeutigkeitsregeln bekommst du Buchungen ohne Datum und doppelte Kundinnen.
- Das Löschen vergessen. Entscheide, ob das Löschen einer Kundin auch ihre Buchungen löscht, sie behält oder blockiert wird.
- Produktionsdaten zum Experimentieren nutzen. Teste riskante Änderungen zuerst an einem sicheren Ort und halte Backups bereit.
- Die Tabellenkalkulation ewig als Datenbank behandeln. Tabellenkalkulationen sind toll zum Starten, aber sie tun sich schwer mit vielen gleichzeitigen Nutzern und Berechtigungen. Siehe wie du eine Tabellenkalkulation in eine App verwandelst.
Was du deinen KI-Builder fragen solltest
- „Speichere das in einer Datenbank, nicht im Browser. Sag mir, welche Tabellen du anlegst.“
- „Zeige mir das Schema als einfache Tabelle: jede Tabelle, ihre Spalten und wie sie verknüpft sind.“
- „Eine Kundin kann viele Buchungen haben; jede Buchung hat genau eine Leistung und genau eine Mitarbeiterin oder einen Mitarbeiter.“
- „Mache E-Mail für Kundinnen Pflicht und eindeutig.“
- „Verhindere, dass sich zwei Buchungen derselben Mitarbeiterin überschneiden.“
- „Nur die angemeldete Inhaberin kann alle Buchungen lesen; Kundinnen sehen nur ihre eigenen. Erzwinge das auf dem Server.“
- „Wenn ich eine Leistung lösche, lösche keine vergangenen Buchungen; markiere die Leistung stattdessen als inaktiv.“
Datenbanken in Mythex
Wenn deine App Daten speichern muss, fügt Mythex dem Projekt eine eigene Postgres-Datenbank hinzu. Du kannst im Chat darum bitten („speichere Warteliste-Anmeldungen in einer Datenbank“) oder den Befehl /database verwenden. Verbindungsdaten werden automatisch an deine App übergeben, und der Agent legt die Tabellen an. Die Datenbank schläft nach fünf Minuten Inaktivität und wacht bei der nächsten Anfrage auf; bei veröffentlichten Apps wird die Zeit berechnet, in der sie wach war, aus demselben Guthaben wie das Bauen. Sie ist im Free- und im Pro-Tarif verfügbar. Die Datenbank-Dokumentation beschreibt die Details, und die App-Vorlagen bieten datengetriebene Startpunkte.
Fragen
Was ist eine Datenbank einfach erklärt?
Eine Datenbank ist ein strukturierter Speicher für Informationen, in den eine App schreiben und aus dem sie lesen kann, etwa Nutzer, Bestellungen oder Buchungen. Anders als Daten, die nur im Browser-Tab liegen, bleiben sie nach einem Neuladen, einem Neustart oder wenn jemand die App auf einem anderen Gerät öffnet, erhalten.
Ist eine Tabellenkalkulation eine Datenbank?
Eine Tabellenkalkulation kann dieselbe Art von Daten speichern, ist aber nicht für Apps gebaut. Eine echte Datenbank erzwingt Regeln dafür, was jede Spalte enthält, verknüpft Tabellen zuverlässig, verarbeitet viele gleichzeitige Schreibzugriffe und steuert, wer was lesen darf.
Was ist der Unterschied zwischen SQL- und NoSQL-Datenbanken?
SQL-(relationale) Datenbanken wie Postgres und MySQL speichern Daten in Tabellen mit festen Spalten und Beziehungen zwischen ihnen. NoSQL-Datenbanken wie MongoDB speichern flexiblere Dokumente. Die meisten Geschäfts-Apps, etwa Buchungen, CRMs oder Shops, passen gut zum relationalen Modell.
Braucht meine App eine Datenbank?
Ja, wenn sie sich merken muss, was Menschen eingeben, etwa Anmeldungen, Bestellungen, Nachrichten oder Einstellungen, und es später oder einer anderen Person zeigen soll. Eine rein informative Website ohne Formulare, die Daten speichern, braucht meist keine.