Was ist eine Datenbank?

Relationale Datenbanken

Relationale Datenbanken (z. B. PostgreSQL, MySQL) speichern Daten in Tabellen mit Zeilen und Spalten — vergleichbar mit einer sehr mächtigen Excel-Tabelle. Beziehungen zwischen Tabellen (etwa Kunde ↔ Bestellung) machen sie stark. Abgefragt werden sie mit SQL.

Dokumentbasierte Datenbanken

Dokumentbasierte Datenbanken (z. B. MongoDB) speichern Daten als flexible JSON-ähnliche Dokumente. Sie eignen sich, wenn die Struktur variabel ist oder sich schnell ändert.

Schlüssel und Beziehungen

Das Herzstück einer relationalen Datenbank sind ihre Beziehungen. Jede Zeile einer Tabelle erhält einen Primärschlüssel — eine eindeutige Kennung, meist eine ID. Verweist eine andere Tabelle über einen Fremdschlüssel auf diese ID, entsteht eine Verbindung: Eine Bestellung „gehört“ zu genau einem Kunden. So lassen sich Daten sauber trennen und trotdem verknüpfen, ohne Informationen doppelt zu speichern. Genau daher kommt das Wort „relational“: Es geht um die Beziehungen zwischen den Daten.

Normalisierung: Daten nicht doppelt speichern

Ein gut entworfenes Datenmodell speichert jede Information genau einmal. Steht die Adresse eines Kunden bei jeder seiner Bestellungen erneut, führt eine Umzugsmeldung zu mühsamer, fehleranfälliger Pflege an vielen Stellen. Bei der Normalisierung legt man solche Daten stattdessen einmal an und verknüpft sie über Schlüssel. Das hält die Datenbank konsistent und spart Speicher. In der Praxis wägt man ab, wie streng man normalisiert, denn manchmal ist bewusste Redundanz aus Geschwindigkeitsgründen sinnvoll.

Indizes und Transaktionen

Zwei Konzepte machen professionelle Datenbanken aus. Ein Index funktioniert wie das Stichwortverzeichnis eines Buches: Statt jede Zeile einzeln durchzugehen, findet die Datenbank gesuchte Werte sofort — bei großen Tabellen der Unterschied zwischen Millisekunden und Sekunden. Eine Transaktion wiederum fasst mehrere Schritte zu einer Einheit zusammen, die entweder ganz oder gar nicht ausgeführt wird. Bei einer Überweisung darf nicht Geld abgebucht, aber nicht gutgeschrieben werden — Transaktionen garantieren, dass die Daten immer stimmig bleiben.

ORMs: die Datenbank aus dem Code ansprechen

In den wenigsten Anwendungen schreibt man Abfragen von Hand direkt in den Programmcode. Stattdessen kommt meist ein ORM zum Einsatz — eine Zwischenschicht, die Tabellen auf Objekte des eigenen Codes abbildet. Statt einer Abfragezeichenkette ruft man eine Methode auf und bekommt fertige, typisierte Objekte zurück. Das erspart viel Fleißarbeit, schützt automatisch vor eingeschleusten Abfragen und macht Tippfehler schon beim Entwickeln sichtbar. Der Preis ist Distanz zur Datenbank: Was das ORM im Hintergrund tatsächlich abschickt, sieht man nicht sofort — und genau dort entstehen später die Geschwindigkeitsprobleme, wenn niemand hinschaut.

Migrationen: das Schema wächst mit

Ein Datenmodell ist nie fertig — es kommen Felder hinzu, Tabellen werden umbenannt, Beziehungen ändern sich. Solche Änderungen macht man nicht per Hand auf dem Live-System, sondern schreibt sie als Migration: eine kleine, nummerierte Datei, die genau beschreibt, wie das Schema von einem Stand zum nächsten kommt. Weil diese Dateien im Repository liegen, kann jeder Entwickler und jeder Server dieselbe Reihenfolge nachvollziehen. Kritisch sind Änderungen an Tabellen mit vielen Daten: Sie brauchen einen Plan für den laufenden Betrieb, damit die Anwendung während der Umstellung erreichbar bleibt — und ein Backup, bevor es losgeht.

Verbindungen sind eine begrenzte Ressource

Eine Anwendung spricht nicht direkt mit Dateien, sondern über Verbindungen mit dem Datenbankserver — und jede davon kostet dort Arbeitsspeicher. Deshalb ist die Zahl gleichzeitiger Verbindungen begrenzt, und zwar meist deutlich niedriger, als Einsteiger vermuten. Damit nicht bei jeder Anfrage eine neue Verbindung aufgebaut wird, hält die Anwendung einen Vorrat bereit und reicht ihn reihum weiter; man nennt das einen Verbindungspool. Besonders wichtig wird das, wenn viele kurzlebige Prozesse gleichzeitig zugreifen: Dann schiebt man einen eigenen Pooler zwischen Anwendung und Datenbank, der die Zugriffe bündelt und den Server vor Überlastung schützt.