Dateien und Datenbanken: relationale und nicht relationale Speicherung, Abfragen und Transaktionen

Warum Programme einen Ort für ihre Daten brauchen

Ein laufendes Programm hält seine Arbeitsdaten im Arbeitsspeicher (RAM), der schnell ist, aber alles vergisst, sobald das Programm endet oder die Maschine neu startet (siehe Was Software ist). Alles, was einen Neustart überstehen muss, etwa ein Kundenkonto, eine Bestellung oder ein Krankenhaustermin, muss auf einen Speicher geschrieben werden, der seinen Inhalt ohne Strom behält: eine Festplatte oder SSD. Daten, die auf diese Weise erhalten bleiben, nennt man persistent, und die Entscheidung, wie man sie persistiert, gehört zu den ersten und langlebigsten Entscheidungen in jedem System.

Die einfachste Art, Daten zu persistieren, ist eine Datei: eine benannte Folge von Bytes, die das Betriebssystem auf der Festplatte ablegt. Dateien eignen sich hervorragend für alles, was von Natur aus ein ganzes Dokument ist: Bilder, PDFs, Videos, Konfiguration, Logs, exportierte Berichte. Systeme legen sie oft in einem Object Storage in der Cloud ab (einem Dienst, der Dateien unter einem Namen speichert) und speichern anderswo nur einen Verweis.

Mühsam werden Dateien, wenn viele Nutzer gleichzeitig kleine Teile strukturierter Daten lesen und ändern. Stellen Sie sich einen Shop vor, der alle Bestellungen in einer einzigen Tabellenkalkulationsdatei führt. Zwei Kunden schließen im selben Moment den Bezahlvorgang ab: Wessen Änderung gewinnt? Der Server stürzt mitten beim Speichern ab: Ist die Datei nun halb alt, halb neu? Ein Supportmitarbeiter will die Bestellungen eines Kunden sehen: Muss das Programm die ganze Datei lesen? Jemand tippt eine Kundennummer ein, die es nicht gibt: Wer hält ihn auf? Jedes Programm, das die Datei nutzt, müsste jedes dieser Probleme lösen, und zwar identisch.

Was eine Datenbank ist

Eine Datenbank ist eine organisierte Sammlung von Daten, und das Programm, das sie verwaltet, ist ein Datenbankmanagementsystem (DBMS), etwa PostgreSQL, MySQL, Microsoft SQL Server, Oracle Database oder SQLite. Oft sagt man für beides „die Datenbank“. Das DBMS löst die Probleme mit Dateien ein für alle Mal, für alle: Es lässt viele Nutzer gleichzeitig arbeiten, ohne dass sie sich gegenseitig in die Quere kommen, findet Daten schnell, weist Daten zurück, die gegen die Regeln verstoßen, und kehrt nach einem Absturz in einen korrekten Zustand zurück.

Die Analogie ist eine Bibliothek. Ein Stapel Papiere auf einem Schreibtisch funktioniert, solange Sie ihn allein nutzen. Eine Bibliothek hat einen Katalog, Regeln dafür, wo was steht, eine Aufzeichnung, wer was ausgeliehen hat, und eine Bibliothekarin, die nicht zulässt, dass zwei Personen dasselbe Exemplar nehmen. Anwendungen fassen die Regale nicht an; sie fragen die Bibliothekarin.

In den meisten Geschäftssystemen läuft das DBMS als eigener Serverprozess, oft auf einer eigenen Maschine, und Anwendungen sprechen über das Netzwerk mit ihm (siehe Wie Computer kommunizieren). SQLite ist eine bekannte Ausnahme: Es ist eine Bibliothek, die innerhalb der Anwendung läuft und die ganze Datenbank in einer einzigen Datei speichert, weshalb man es in Smartphones, Browsern und kleinen Werkzeugen findet.

Relationale Datenbanken: Tabellen, Schlüssel und Beziehungen

Die am weitesten verbreitete Art von Datenbank ist die relationale Datenbank, die auf einem Modell beruht, das Edgar F. Codd von IBM 1970 veröffentlichte. Die Daten liegen in Tabellen. Jede Tabelle beschreibt eine Art von Ding (Kunden, Bestellungen, Produkte). Jede Zeile ist eine Instanz dieses Dings (ein Kunde), und jede Spalte ist ein Fakt darüber (Name, E-Mail-Adresse, Beitrittsdatum), mit einem deklarierten Typ wie Ganzzahl, Text, Datum oder Dezimalzahl.

Jede Tabelle hat einen Primärschlüssel: eine Spalte (oder Kombination von Spalten), deren Wert für jede Zeile eindeutig und nie leer ist, etwa customer_id. Ein Fremdschlüssel ist eine Spalte in einer Tabelle, die den Primärschlüssel einer Zeile in einer anderen Tabelle enthält. Eine Bestellung hat eine Spalte customer_id, die angibt, welcher Kunde sie aufgegeben hat. Wird sie als Fremdschlüssel deklariert, weist das DBMS eine Bestellung für Kunde 999 zurück, wenn es keinen Kunden 999 gibt: Das nennt man referenzielle Integrität.

Die Gesamtheit aus Tabellen, Spalten, Typen, Schlüsseln und Regeln ist das Schema. Das Schema ist ein Vertrag: Jedes Programm, das die Datenbank nutzt, kann sich darauf verlassen, dass eine Bestellung immer einen gültigen Kunden und einen Preis hat, der eine Zahl ist. Ein Schema später zu ändern, wenn Millionen von Zeilen und mehrere Programme davon abhängen, ist möglich, erfordert aber Sorgfalt; deshalb hat die Schemaevolution in Kapitel 7 einen eigenen Abschnitt.

Relationale Entwürfe versuchen, jeden Fakt nur einmal zu speichern. Die E-Mail-Adresse eines Kunden steht in einer Zeile der Kundentabelle und wird nicht in jede Bestellung kopiert. Das nennt man Normalisierung. Eine Aktualisierung erfolgt so an einer Stelle und kann keine widersprüchlichen Kopien hinterlassen. Der Preis für diese Ordnung ist, dass man zur Beantwortung einer Frage oft Tabellen kombinieren muss, und genau dafür gibt es Joins.

Fragen stellen mit SQL

SQL (Structured Query Language, ausgesprochen „S-Q-L“ oder „Sequel“) ist die Sprache, mit der man mit relationalen Datenbanken arbeitet. Sie wurde in den 1970er-Jahren bei IBM entwickelt und Ende der 1980er-Jahre zu einem ANSI- und ISO-Standard; jedes große relationale DBMS spricht sie, jeweils mit kleinen Dialektunterschieden. SQL ist deklarativ: Sie beschreiben das gewünschte Ergebnis, nicht die Schritte, um es zu finden. Der Query Planner des DBMS wählt die Schritte, zum Beispiel ob eine ganze Tabelle gelesen oder ein Index genutzt wird.

Ein Join kombiniert Zeilen aus zwei oder mehr Tabellen anhand übereinstimmender Spalten, meist ein Fremdschlüssel gegen den Primärschlüssel, auf den er verweist. Die zweite Abfrage unten listet jede Position der Bestellungen eines Kunden zusammen mit dem Produktnamen auf und greift dabei auf drei Tabellen gleichzeitig zu.

-- One customer's orders since 1 October, newest first
SELECT order_id, status, placed_at
FROM orders
WHERE customer_id = 42
  AND placed_at >= '2026-10-01'
ORDER BY placed_at DESC;

-- Each order line with the product's name (a join)
SELECT o.order_id, p.name, i.quantity, i.unit_price
FROM orders AS o
JOIN order_items AS i ON i.order_id = o.order_id
JOIN products AS p ON p.product_id = i.product_id
WHERE o.customer_id = 42;

INSERT, UPDATE und DELETE ändern Daten, und CREATE TABLE definiert das Schema. Anwendungscode sendet SQL oft über einen objektrelationalen Mapper (ORM), eine Bibliothek, die Zeilen in Objekte umwandelt. ORMs sparen Tipparbeit, verbergen aber das tatsächlich gesendete SQL; ein klassisches Performance-Problem ist ein ORM, das unbemerkt eine Abfrage pro Zeile statt eines einzigen Joins absetzt.

Indizes: das Register des Buchs, nicht das ganze Buch

Ohne Hilfe kann die Datenbank alle Bestellungen von Kunde 42 nur finden, indem sie jede Zeile der Bestelltabelle liest und prüft: ein Full Table Scan, der in der Notation aus Daten und Algorithmen O(n) ist. Ein Datenbankindex ist eine zusätzliche, sortierte Datenstruktur, die Werte einer Spalte den Zeilen zuordnet, die sie enthalten, so wie das Register hinten in einem Buch Wörter den Seitenzahlen zuordnet. Die meisten relationalen Datenbanken verwenden standardmäßig einen B-Baum, einen breiten, flachen, stets balancierten Baum, der einen Wert in O(log n) Schritten findet.

Primärschlüssel werden automatisch indiziert. Weitere Indizes legt man gezielt für Spalten an, nach denen Abfragen filtern, verknüpfen oder sortieren: CREATE INDEX idx_orders_customer ON orders (customer_id);. Indizes sind nicht kostenlos. Jedes Einfügen, Aktualisieren oder Löschen muss auch jeden Index der Tabelle aktualisieren, und jeder Index belegt Festplattenplatz und Arbeitsspeicher. Eine Tabelle mit fünfzehn Indizes liest schnell und schreibt langsam. Die Wahl der Indizes ist eine Abwägung, die sich an den Abfragen orientiert, die das System tatsächlich ausführt, und damit ein frühes Beispiel für die Abwägung zwischen Platz und Zeit, die sich durch die gesamte Architektur zieht.

Transaktionen und ACID: die Banküberweisung

Um 100 Pfund von Alices Konto auf Bobs Konto zu überweisen, braucht es zwei Änderungen: 100 bei Alice abziehen, 100 bei Bob gutschreiben. Stürzt der Server nach der ersten Änderung und vor der zweiten ab, sind 100 Pfund verschwunden. Laufen zwei Überweisungen von Alice gleichzeitig, sehen womöglich beide einen Kontostand von 150 und beide gelingen, sodass ihr Konto überzogen ist. Eine Transaktion fasst mehrere Operationen zu einer Arbeitseinheit zusammen, die entweder vollständig abgeschlossen wird (Commit) oder gar keine Wirkung hat (Rollback).

Die Garantien einer Transaktion werden als ACID zusammengefasst, ein Akronym, das Theo Härder und Andreas Reuter 1983 prägten, aufbauend auf früheren Arbeiten von Jim Gray:

import sqlite3

conn = sqlite3.connect("bank.db")
# The accounts table was created with CHECK (balance >= 0)

def transfer(from_id, to_id, amount):
    try:
        with conn:  # one transaction: commit on success, rollback on error
            debit = conn.execute(
                "UPDATE accounts SET balance = balance - ? WHERE id = ?",
                (amount, from_id))
            credit = conn.execute(
                "UPDATE accounts SET balance = balance + ? WHERE id = ?",
                (amount, to_id))
            if debit.rowcount != 1 or credit.rowcount != 1:
                raise ValueError("No such account")  # forces a rollback
        return "Transfer complete"
    except (sqlite3.Error, ValueError):
        return "Transfer refused: no account was changed"

Beachten Sie die Prüfung von rowcount (der Anzahl der Zeilen, die jede Aktualisierung geändert hat): Eine Aktualisierung, die auf kein Konto passt, ist für die Datenbank kein Fehler, daher muss der Code sie selbst als Fehler behandeln. Zwei weitere Details sind über dieses Beispiel hinaus wichtig. Die Platzhalter ? übergeben Werte getrennt vom SQL-Text; das ist die Standardabwehr gegen SQL-Injection, einen Angriff, bei dem Benutzereingaben als Code in eine Abfrage eingeschleust werden (Kapitel 8 kommt darauf zurück). Und das Versprechen der Dauerhaftigkeit wird durch ein Write-Ahead-Log eingehalten: Das DBMS schreibt jede Änderung in ein nur erweiterbares Log auf der Festplatte, bevor es den Commit bestätigt, sodass es nach einem Absturz Arbeit wiederholen oder rückgängig machen kann, um einen korrekten Zustand zu erreichen.

Isolation ist die subtilste Eigenschaft. Vollständige Isolation (serialisierbar genannt) ist sicher, begrenzt aber, wie viel Arbeit parallel laufen kann; daher bieten Datenbanken schwächere Isolationsebenen, die etwas Schutz gegen Geschwindigkeit tauschen, und viele nutzen standardmäßig eine schwächere Ebene. Welche Anomalien jede Ebene zulässt, behandelt Transaktionen, ACID und Isolationsebenen. Vorerst ist der Kerngedanke, dass eine einzelne Datenbank innerhalb einer Transaktion starke, gut verstandene Garantien gibt und dass diese Garantien viel schwerer zu erreichen sind, sobald Daten über mehrere Datenbanken oder Services verteilt sind.

NoSQL: andere Formen von Daten

Relationale Datenbanken sind nicht die einzige Option. NoSQL ist ein Sammelbegriff, populär geworden durch ein Meetup 2009 in San Francisco, für Datenbanken, die nicht das relationale Modell verwenden. Sie entstanden, um sehr große, über viele Maschinen verteilte Datenmengen, flexible Datenformen und Zugriffsmuster zu bewältigen, die Tabellen nur umständlich bedienen. Der Name sagt, was sie nicht sind, und umfasst daher recht unterschiedliche Familien.

Fachleute sind sich über den Standard uneinig. Ein Lager sagt, man solle mit einer relationalen Datenbank beginnen, sofern es keinen klaren Grund dagegen gibt: SQL ist weithin bekannt, Transaktionen und Joins sind mächtig, und moderne relationale Systeme speichern auch JSON-Dokumente gut. Das andere Lager sagt, man solle von Anfang an den Speicher wählen, der zum Zugriffsmuster passt, weil ein Dokumenten- oder Key-Value-Store für die richtige Last einfacher sein und günstiger skalieren kann. Beide sind sich einig, dass viele reale Systeme mehr als eine Art nutzen, jede dort, wo sie passt; das nennt man polyglotte Persistenz. Der Abschnitt Eine Datenbank wählen in Kapitel 7 bietet einen strukturierten Weg zur Entscheidung.

Ausgearbeitetes Beispiel: das Schema eines Onlineshops

Nehmen Sie einen kleinen Onlineshop. Er muss wissen, wer seine Kunden sind, was er verkauft und wer was bestellt hat. Ein erster Versuch könnte alles in eine Tabelle packen, mit einer Zeile pro Bestellung und den Spalten product1, product2, product3. Das scheitert, sobald jemand vier Dinge bestellt, und es kopiert Name und Adresse des Kunden in jede Bestellung.

Backups, Wiederherstellung und Managed Databases

Festplatten fallen aus, Menschen führen das falsche DELETE aus, Software hat Bugs, und Angreifer verschlüsseln Daten, um Lösegeld zu erpressen. Ein Backup ist eine Kopie der Daten, die getrennt aufbewahrt wird und aus der die Datenbank wiederhergestellt werden kann. Drei professionelle Gewohnheiten zählen. Ein Backup, das nie wiederhergestellt wurde, ist eine Hoffnung, kein Backup; deshalb proben Teams Wiederherstellungen und messen deren Dauer. Kopien werden an mehr als einem Ort aufbewahrt (eine verbreitete Faustregel lautet: drei Kopien, auf zwei Arten von Medien, eine davon extern). Und ein Replikat, eine zweite Datenbank, die die erste fortlaufend kopiert, schützt vor dem Ausfall einer Maschine, aber nicht vor Fehlern: Ein falsches DELETE erreicht das Replikat innerhalb von Millisekunden. Viele Datenbanken können ein regelmäßiges Vollbackup mit dem gespeicherten Transaktionslog kombinieren, um auf jeden beliebigen Zeitpunkt wiederherzustellen; das nennt man Point-in-Time-Recovery.

Eine Datenbank gut zu betreiben (Patches einspielen, Tuning, Replikation, Backups und Wiederherstellung um drei Uhr morgens) ist anspruchsvolle, nie endende Arbeit; deshalb verkaufen Cloud-Anbieter eine Managed Database: Amazon RDS, Azure SQL Database und Google Cloud SQL sind Beispiele. Der Anbieter kümmert sich um die Maschinen, Software-Updates, automatische Backups und das Failover auf eine Standby-Kopie; beim Kunden bleiben weiterhin das Schema, die Abfragen, die Indizes, die Zugriffsrechte und die Kosten. Managed Services werden in Server und die Cloud allgemeiner behandelt.

Warum das für die Architektur wichtig ist

Daten überdauern meist den Code um sie herum: Anwendungen werden alle paar Jahre neu geschrieben, während Kundendaten und Krankengeschichten über Jahrzehnte aufbewahrt werden. Entscheidungen darüber, wo Daten liegen, welche Art von Datenbank sie hält, welches Programm für sie zuständig ist und welche Garantien sie brauchen, gehören daher zu den am teuersten rückgängig zu machenden. Mehrere große Architekturfragen erwachsen direkt aus diesem Abschnitt: ob jeder Service seine eigene Datenbank besitzen sollte (Datenhoheit), welche Datenbank zu welcher Aufgabe passt (Eine Datenbank wählen) und wie man Daten korrekt hält, wenn eine geschäftliche Aktion mehrere Datenbanken berührt und keine einzelne ACID-Transaktion mehr verfügbar ist (Sagas). Wenn ein Architekt fragt: „Wo liegt dafür die Source of Truth?“, dann ist dieser Abschnitt der Grund.