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

Wenn eine Web-App schlecht aussieht, fällt es 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 simple Änderung zieht eine monatelange Migration nach sich. Das ist die tückische Natur schlechten Datenbankdesigns: Es wächst still mit, bis es das gesamte System lähmt.

INREMA erlebt das regelmäßig in der Praxis. Mittelständische Unternehmen beauftragen die Entwicklung einer Web-App, der Fokus liegt auf dem Frontend — auf Farben, Layouts, Benutzerführung. Die Datenstruktur dahinter wird als technisches Detail abgehakt. Monate später steht dann die Frage im Raum: Warum lädt die Übersichtsseite mit 500 Datensätzen plötzlich 8 Sekunden? Warum stimmen Bestände in zwei Ansichten nicht überein? Die Antwort liegt fast immer in der Datenbankarchitektur.

Datenbankdesign ist keine rein technische Disziplin. Es ist eine strategische Entscheidung, die Einfluss auf Skalierbarkeit, Wartbarkeit, Datenschutz und Betriebskosten hat. Wer diese Entscheidung richtig trifft — am besten vor der ersten Zeile Code — spart sich langfristig erhebliche Kosten und Nerven.

In diesem Artikel erklärt INREMA, welche Datenbanktypen es gibt, welche häufigen Fehler beim Datenbankdesign gemacht werden — und wie man von Anfang an die richtige Grundlage legt.

Die Wahl des Datenbanksystems ist eine der folgenreichsten Entscheidungen im Projektstart. Es gibt kein universell richtiges System — aber es gibt häufige falsche Entscheidungen, die aus Unwissen oder Bequemlichkeit getroffen werden.

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. INREMA setzt MySQL standardmäßig ein, wenn Geschäftsdaten — also 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 (z. B. JSON-Spalten, Arrays, geografische Daten), bietet strengere ACID-Konformität und ist besser geeignet, 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 Features, die man nie braucht.

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

Normalisierung beschreibt den Prozess, eine Datenbankstruktur so zu gestalten, dass Redundanzen vermieden werden. Das klingt technisch — ist aber im Kern gesunder Menschenverstand. Wenn ein Kundenname an zwanzig Stellen in der Datenbank steht, muss er bei einer Namensänderung an zwanzig Stellen aktualisiert werden. Wer das vergisst, hat inkonsistente Daten. Wer es vergisst und es nicht merkt, hat ein ernstes Problem.

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 von deren 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, die über Fremdschlüssel miteinander verknüpft sind. Eine Bestellung speichert nicht die vollständige Lieferadresse, sondern eine Referenz auf den Adressdatensatz. Das spart Speicher, verhindert Inkonsistenzen und macht Änderungen einfach wartbar.

Vollständige Normalisierung ist nicht immer das Ziel. In Spezialfällen — zum Beispiel bei Read-heavy-Systemen oder Data-Warehouses — kann bewusste Denormalisierung aus Performance-Gründen sinnvoll sein. Aber das ist eine bewusste Entscheidung, keine Nachlässigkeit.