Datenbankdesign: Warum die Grundlage Ihrer Web-App wichtiger ist als das Design

Die unsichtbare Achillesferse jeder Web-App

Wenn eine Web-App schlecht aussieht, fällt das sofort auf. Wenn die Datenbank schlecht strukturiert ist, merkt es zunächst niemand – bis es zu spät ist. Daten werden doppelt gespeichert, Abfragen dauern Sekunden statt Millisekunden, und eine scheinbar einfache Änderung zieht eine monatelange Migration nach sich. Schlechtes Datenbankdesign wächst still mit, bis es das gesamte System lähmt.

Wir erleben das regelmäßig in der Praxis: Der Fokus einer neuen Web-App liegt auf dem Frontend – auf Farben, Layout, Benutzerführung. Die Datenstruktur dahinter wird als technisches Detail abgehakt. Monate später steht die Frage im Raum, warum die Übersichtsseite mit 500 Datensätzen plötzlich acht Sekunden lädt oder warum Bestände in zwei Ansichten nicht übereinstimmen. Die Antwort liegt fast immer in der Datenbankarchitektur.

Datenbankdesign ist keine rein technische Nebensache. Es ist eine strategische Entscheidung mit Einfluss auf Skalierbarkeit, Wartbarkeit, Datenschutz und Betriebskosten. Wer sie richtig trifft – am besten vor der ersten Zeile Code –, spart sich langfristig erhebliche Kosten und Nerven.

MySQL, PostgreSQL oder MongoDB: Welches System passt?

Die Wahl des Datenbanksystems ist eine der folgenreichsten Entscheidungen zu Projektbeginn. Ein universell richtiges System gibt es nicht – aber häufige Fehlentscheidungen aus Unwissen oder Bequemlichkeit.

MySQL ist das meistgenutzte relationale Datenbanksystem weltweit und für die meisten mittelständischen Web-Apps die richtige Wahl. Es ist stabil, gut dokumentiert, von nahezu jedem Hosting-Anbieter unterstützt und performant bei klar strukturierten Daten. Wir setzen MySQL standardmäßig ein, wenn Geschäftsdaten – Kunden, Bestellungen, Rechnungen, Produkte – im Mittelpunkt stehen. Die Stärke liegt in der klaren Tabellenstruktur, in Fremdschlüsseln, die Datenkonsistenz erzwingen, und in der ausgereiften Abfrageoptimierung.

PostgreSQL geht einen Schritt weiter: Es unterstützt komplexere Datentypen (etwa JSON-Spalten, Arrays, geografische Daten), bietet strengere ACID-Konformität und eignet sich besser, wenn Anwendungen hochkomplexe Auswertungen oder Reporting-Funktionen direkt in der Datenbank durchführen. Für viele Standard-Apps ist PostgreSQL allerdings Overengineering – man zahlt mit mehr Konfigurationsaufwand für Funktionen, die nie gebraucht werden.

MongoDB ist eine dokumentenbasierte NoSQL-Datenbank. Statt Tabellen gibt es Sammlungen von JSON-ähnlichen Dokumenten – das klingt flexibel und ist es auch. Flexibilität hat aber ihren Preis: Ohne Schema-Disziplin entstehen schnell inkonsistente Datenstrukturen, die spätere Auswertungen erschweren. MongoDB ist sinnvoll, wenn sich die Datenstruktur häufig ändert, wenn keine festen Beziehungen zwischen Datensätzen bestehen oder wenn sehr große Mengen unstrukturierter Daten verarbeitet werden.

Normalisierung: Ordnung im Datenmodell

Normalisierung beschreibt, eine Datenbankstruktur so zu gestalten, dass Redundanzen vermieden werden – im Kern gesunder Menschenverstand. Steht ein Kundenname an zwanzig Stellen in der Datenbank, muss er bei einer Namensänderung an zwanzig Stellen aktualisiert werden. Wer das vergisst, hat inkonsistente Daten.

Die erste Normalform verlangt, dass jede Tabellenzelle nur einen einzigen Wert enthält – keine kommagetrennten Listen, keine versteckten Mehrfachwerte. Die zweite Normalform stellt sicher, dass alle Felder einer Tabelle tatsächlich vom Primärschlüssel abhängen. Die dritte Normalform eliminiert transitive Abhängigkeiten: Daten, die eigentlich zu einer anderen Entität gehören, bekommen eine eigene Tabelle.

In der Praxis bedeutet das: Kunden, Adressen, Bestellungen und Produkte gehören in separate Tabellen, verknüpft über Fremdschlüssel. Eine Bestellung speichert nicht die vollständige Lieferadresse, sondern eine Referenz auf den Adressdatensatz. Das spart Speicher, verhindert Inkonsistenzen und macht Änderungen wartbar. Vollständige Normalisierung ist nicht immer das Ziel – in Spezialfällen, etwa bei Read-heavy-Systemen, kann bewusste Denormalisierung aus Performance-Gründen sinnvoll sein. Das sollte dann aber eine bewusste Entscheidung sein, keine Nachlässigkeit.

In diesen Schritten entsteht ein solides Datenbankdesign

• Anforderungen vor dem Datenmodell klären: Welche Daten entstehen, wie hängen sie zusammen, welche Abfragen werden häufig gebraucht? Ein Entity-Relationship-Diagramm macht die Struktur sichtbar, bevor Probleme im Code landen.
• Den richtigen Datenbanktyp wählen: relational (MySQL, PostgreSQL) oder dokumentenbasiert (MongoDB) – auf Basis der Datenstruktur, nicht auf Basis von Trends.
• Normalisierung konsequent umsetzen: jede Entität eine eigene Tabelle, Beziehungen über Fremdschlüssel, bewusste Denormalisierung dokumentieren.
• Indizes gezielt setzen: auf Spalten, die häufig in WHERE- oder JOIN-Bedingungen auftauchen, besonders Fremdschlüssel, Status-Felder und Datumsangaben.
• Backup-Strategie von Anfang an einrichten: automatische tägliche Backups mit Aufbewahrung über mindestens 30 Tage, dazu regelmäßige Restore-Tests – ein ungetestetes Backup ist kein Backup.
• Migrationen versionieren und dokumentieren: jede Änderung an der Datenbankstruktur als Migrations-Skript, damit Updates sicher und reproduzierbar bleiben.

Ein häufiges Muster: Das Frontend wird fertiggestellt, die Datenbank passend dazu gebastelt. Das Ergebnis orientiert sich an der Oberfläche, nicht an den Daten und ihren Beziehungen. In einem konkreten Fall landeten so Produktvarianten und Hauptprodukte in derselben Tabelle, unterschieden nur durch ein Typ-Flag. Das funktionierte mit 50 Produkten – mit 5.000 Produkten und komplexen Filterabfragen war die Performance nicht mehr akzeptabel. Die Migration auf eine saubere Tabellentrennung kostete drei Wochen Entwicklungszeit, mehr als das ursprüngliche Datenbankdesign gebraucht hätte.

Bevor bei uns die erste Zeile Anwendungscode geschrieben wird, steht deshalb immer ein Datenmodell-Review: Welche Entitäten gibt es, wie hängen sie zusammen, welche Abfragen werden dominieren? Dieser Schritt dauert typisch einen halben Tag und verhindert wochenlange Nacharbeit.