Datenbanken, SQL & Datenmodellierung

Datenbanken unterscheiden sich vor allem darin, welche Form von Daten sie besonders gut abbilden. Relationale Systeme wie PostgreSQL, MySQL oder SQLite legen Daten in Tabellen mit festem Schema ab und sind der Standard, wenn Beziehungen und Konsistenz zählen — Bestellungen, Konten, Buchungen. Dokumentdatenbanken speichern flexible, verschachtelte Datensätze und passen zu Inhalten, deren Struktur sich pro Eintrag unterscheidet.

Daneben gibt es spezialisierte Typen: Schlüssel-Wert-Speicher wie Redis für sehr schnelle Zugriffe auf kleine Datenmengen, etwa Sitzungen oder Zwischenspeicher; Graphdatenbanken für stark vernetzte Daten wie soziale Beziehungen oder Empfehlungen; Zeitreihendatenbanken für Messwerte; Suchmaschinen für Volltextsuche mit Relevanzbewertung.

In der Praxis ist die Frage selten entweder-oder. Viele Anwendungen nutzen ein relationales System als verlässliche Quelle der Wahrheit und ergänzen es um einen Zwischenspeicher oder einen Suchindex. Entscheidend ist, dass es genau eine Stelle gibt, an der Daten verbindlich gelten.

Ein gutes Datenmodell beginnt nicht bei Tabellen, sondern beim Fachgebiet. Welche Dinge gibt es — Kunde, Produkt, Bestellung? Welche Eigenschaften haben sie? Und wie hängen sie zusammen? Aus diesen Beziehungen ergeben sich die klassischen Muster: eins zu eins, eins zu viele und viele zu viele, letzteres über eine Verbindungstabelle.

Drei Modellierungsfehler kosten später besonders viel. Erstens: mehrere Informationen in ein Feld pressen, etwa eine Liste von Kategorien als kommagetrennter Text. Zweitens: dieselbe Information an mehreren Stellen führen, sodass Änderungen auseinanderlaufen. Drittens: fachliche Werte als Schlüssel verwenden, etwa eine E-Mail-Adresse, die sich ändern kann.

Wichtig ist außerdem, Regeln dort zu verankern, wo sie nicht umgangen werden können. Eindeutigkeits- und Fremdschlüsselbedingungen, Pflichtfelder und Wertebereiche sind kein bürokratischer Ballast, sondern der Grund, warum die Daten nach Jahren noch stimmen. Anwendungscode kann fehlerhaft sein oder ausgetauscht werden — die Datenbank bleibt.

Sobald Datenmengen wachsen, wird die Frage nach der Zugriffsgeschwindigkeit konkret. Indizes sind zusätzliche Suchhilfen, die das Finden dramatisch beschleunigen, dafür aber Speicher kosten und jedes Schreiben etwas verlangsamen. Deshalb indexiert man gezielt die Spalten, nach denen tatsächlich gefiltert, sortiert oder verknüpft wird — und prüft mit dem Ausführungsplan der Datenbank, ob eine langsame Abfrage den Index überhaupt nutzt.

Verlässlichkeit sichern Transaktionen zu: Mehrere Schreibvorgänge gelten entweder gemeinsam oder gar nicht. Diese Eigenschaft ist der Grund, warum Geldbeträge und Bestände in relationale Systeme gehören. Dazu kommt Datenschutz: Personenbezogene Daten sollten sparsam erhoben, klar begründet und mit Löschfristen versehen sein.

Schließlich verändert sich jedes Schema mit der Zeit. Änderungen gehören deshalb als versionierte Migrationsschritte ins Projekt, nicht als Handarbeit auf dem Produktivsystem. Und Backups zählen erst, wenn die Wiederherstellung mindestens einmal geübt wurde.

Zwischen Anwendung und Datenbank liegt eine eigene Schicht mit eigenen Fallstricken. Verbindungen sind eine begrenzte Ressource und werden deshalb in einem Pool wiederverwendet, statt für jede Anfrage neu aufgebaut zu werden. Wer das übersieht, bringt eine Datenbank schon bei moderater Last an ihre Grenze, obwohl die einzelnen Abfragen völlig harmlos sind.

Zweitens gehören Eingaben von Nutzern niemals per Textverkettung in eine Abfrage. Vorbereitete Anweisungen mit Platzhaltern trennen Befehl und Daten und schließen damit die bekannteste Angriffsklasse auf Datenbanken aus. Ebenso sollte jede Anwendung ein eigenes Datenbankkonto besitzen, das nur die Rechte hat, die sie tatsächlich braucht — und nicht den Verwaltungszugang mitbenutzen.

Drittens die kleinen Festlegungen mit großer Wirkung: Geldbeträge gehören in einen exakten Dezimaltyp und nicht in Fließkommazahlen, Zeitstempel speichert man am besten in koordinierter Weltzeit und rechnet erst bei der Anzeige um, und Löschen ist nicht immer die richtige Antwort — oft ist ein Kennzeichen sinnvoller, damit bestehende Bezüge nicht ins Leere laufen.