Eine klare Geschichte der relationalen Datenbanken — von Codd und SQL bis ACID und ERP — erklärt, warum sie die meisten Business-Apps antreiben und wo sie an ihre Grenzen stoßen.
Eine „Business-Anwendung“ ist jedes System, das den täglichen Betrieb am Laufen hält: Bestellungen entgegennehmen, Rechnungen ausstellen, Kunden nachverfolgen, Inventar verwalten, Lieferanten bezahlen und berichten, was letzte Woche (oder heute Morgen) passiert ist. Ob es sich um ein ERP-System für Einkauf und Finanzen oder CRM-Software für Vertriebsaktivitäten handelt — diese Apps teilen eine Anforderung: Zahlen und Datensätze müssen mit der Realität übereinstimmen.
Eine relationale Datenbank speichert Informationen in Tabellen — denk an Tabellenkalkulationen mit strengeren Regeln. Jede Tabelle hat Zeilen (einzelne Datensätze) und Spalten (Felder wie Kundenname, Bestelldatum oder Preis). Tabellen verbinden sich durch Keys: eine Kunden-ID in der Customers-Tabelle kann von der Orders-Tabelle referenziert werden, sodass das System weiß, welche Bestellungen zu welchem Kunden gehören.
Diese Struktur klingt simpel, ist aber mächtig: sie ermöglicht es einer Business-App, Daten organisiert zu halten, selbst wenn viele Personen und Prozesse gleichzeitig darauf zugreifen.
Relationale Datenbanken wurden aus ein paar praktischen Gründen zur Standardbasis für Business-Anwendungen:
Relationale Systeme haben klare Stärken — besonders Datenintegrität und verlässliche Transaktionen — aber sie bringen auch Zugeständnisse bei Flexibilität und Skalierung mit sich. Wir erklären, warum sie so gut zu klassischem OLTP passen, wo Alternativen besser sind und was sich mit managed Cloud-Datenbanken und neuen Datenanforderungen ändert.
Bevor relationale Datenbanken üblich wurden, lagen Geschäftsdaten in einem Flickenteppich von Dateien: Tabellenkalkulationen auf Netzlaufwerken, einfache Textdateien aus Buchhaltungstools und proprietäre Dateiformate von Anbietern oder internen Entwicklern.
Das funktionierte bei kleinen Firmen mit wenigen Zugriffen. Sobald aber Vertrieb, Buchhaltung und Betrieb dieselben Informationen brauchten, zeigte die dateibasierte Speicherung Schwächen.
Viele Organisationen setzten auf:
Das größte Problem war nicht nur Unbequemlichkeit — es war Vertrauen. Duplikate waren überall: derselbe Kunde tauchte drei Mal mit leicht unterschiedlichen Namen, Adressen oder Zahlungsbedingungen auf.
Updates waren inkonsistent, weil sie davon abhingen, dass Menschen jede Kopie anpassten. Eine neue Telefonnummer wurde vielleicht im Vertriebstabellenblatt aktualisiert, nicht aber in der Abrechnung — mit verpassten Zahlungen oder Lieferverzögerungen als Folge.
Reporting war schwierig, weil Dateien nicht darauf ausgelegt waren, Fragen wie „Welche Kunden sind überfällig und haben gleichzeitig offene Bestellungen?“ zu beantworten. Die Lösung bedeutete manuelle Nachschläge, lange Formelkaskaden in Tabellen oder Scripts, die bei jedem Layoutwechsel brachen.
Dateien können gleichzeitige Bearbeitungen schlecht handhaben. Zwei Personen, die denselben Datensatz aktualisieren, können sich gegenseitig überschreiben, und das Sperren einer Datei bedeutete oft, dass alle anderen warten mussten. Die Performance verschlechterte sich zudem mit wachsender Dateigröße, besonders im Netzwerk.
Firmen benötigten eine gemeinsame Quelle der Wahrheit mit Regeln (damit Daten gültig bleiben) und verlässliche Updates (damit Änderungen entweder vollständig erfolgen oder gar nicht). Dieser Druck bereitete den Boden für relationale Datenbanken — und den Wechsel von „Daten in Dokumenten“ zu „Daten als verwaltetes System“.
1970 schlug IBM-Forscher Edgar F. „Ted“ Codd das relationale Modell vor — eine Idee, die die Art, wie Unternehmen Daten speichern und nutzen, veränderte. Der Durchbruch war kein neues Speichermedium oder schnellerer Computer, sondern eine einfachere Denkweise über Daten, sodass sie konsistent verwaltet werden konnten, selbst wenn sich geschäftliche Anforderungen änderten.
Im Zentrum des relationalen Modells steht ein einfaches Konzept: Informationen in Relationen organisieren, die heute meist als Tabellen verstanden werden. Eine Tabelle enthält Zeilen (Datensätze) und Spalten (Felder). Kunden in eine Tabelle, Rechnungen in eine andere, Produkte in eine weitere.
Was das mächtig machte, waren nicht nur die Tabellen, sondern die Regeln darum:
Diese Struktur machte Daten leichter validierbar, kombinierbar und schwerer versehentlich widersprüchlich.
Frühere Systeme „backten“ Geschäftsregeln und Datenformate oft in die Anwendung ein. Änderte man die Software, riskierte man, wie Dateien gelesen wurden, zu brechen. Änderte man das Dateiformat, musste Teile der Software neu geschrieben werden.
Das relationale Modell förderte eine saubere Trennung: die Datenbank verwaltet Daten und deren Integrität; Anwendungen holen Daten ab und ändern sie über gut definierte Operationen.
Diese Trennung ist wichtig, weil Unternehmen selten stillstehen. Preisregeln ändern sich, Kundenfelder entwickeln sich weiter und Reporting-Anforderungen wachsen. Mit einer relationalen Datenbank können viele Änderungen in Schema oder Abfragen erfolgen, ohne die gesamte Anwendung neu bauen zu müssen.
Sobald Daten in Tabellen mit konsistenten Regeln liegen, werden sie portabler und langlebiger:
Deshalb passte das relationale Modell so gut zu Business-Software: Es verwandelte unordentliche, anwendungsspezifische Daten in ein organisiertes System, das Jahre des Wachstums und Wandels überstehen konnte.
Relationale Datenbanken gewannen das Vertrauen von Unternehmen, weil sie Daten eine verlässliche „Identität“ und eine kontrollierte Art gaben, Datensätze zu verbinden. Diese Identität ist der Key — die Verbindungen sind die Beziehungen.
Ein Primary Key identifiziert eindeutig eine Zeile in einer Tabelle. In einer Customers-Tabelle könnte das CustomerID sein.
Customers(CustomerID, Name, Email)Orders(OrderID, CustomerID, OrderDate, Total)Hier ist CustomerID die stabile Kennung des Kunden, nicht etwas Veränderliches (wie ein Name) oder potenziell Nicht-Eindeutiges (wie eine E-Mail).
Ein Foreign Key ist ein Feld, das auf einen Primary Key in einer anderen Tabelle verweist. In Orders zeigt CustomerID auf Customers.CustomerID.
Diese Struktur vermeidet das Wiederholen von Kundendetails in jeder Bestellzeile. Anstatt Name und Email in jede Order-Zeile zu kopieren, speichert man sie einmal und verknüpft Bestellungen mit dem richtigen Kunden.
Weil die Datenbank weiß, wie Tabellen zusammenhängen, können Sie sie joinen, um Alltagsfragen zu beantworten:
Sie erhalten vollständige Ergebnisse, indem Tabellen zur Abfragezeit kombiniert werden, statt mehrere Kopien derselben Fakten zu pflegen.
Relationale Datenbanken können referentielle Integrität durchsetzen: Eine Bestellung darf keinen Kunden referenzieren, der nicht existiert. Das verhindert Waisendatensätze (Bestellungen ohne gültigen Kunden) und blockiert versehentliche Löschungen, die Verbindungen zerstören würden.
Wenn Keys, Beziehungen und Integritätsregeln vorhanden sind, stimmen Berichte und operative Daten überein. Summen verschieben sich nicht wegen duplizierter Kundenzeilen, und Support-Teams verbringen weniger Zeit mit der Jagd nach „rätselhaften“ Fehlern, die durch fehlende oder falsch zugeordnete IDs entstehen.
Normalisierung heißt im Grunde, Daten so zu strukturieren, dass Fakten nicht mehrfach vorkommen. Es ist eine Reihe von Designgewohnheiten, die verhindern, dass dieselbe Information an mehreren Stellen liegt — denn jede Kopie kann aus dem Tritt geraten.
Stellen Sie sich eine App vor, die Bestellungen speichert. Wenn jede Bestellzeile die vollständige Lieferadresse des Kunden enthält, wird diese Adresse immer wiederholt. Zieht der Kunde um, muss jemand alle vergangenen und zukünftigen Bestellzeilen aktualisieren (oder die App müsste erraten, welche Zeilen angepasst werden sollen). Vergisst man eine, zeigen Reports zwei unterschiedliche „Wahrheiten“ für denselben Kunden.
Bei Normalisierung speichert man die Adresse typischerweise einmal in Customers und referenziert sie von Bestellungen über die CustomerID. Jetzt gibt es einen Ort zum Aktualisieren, und alle Bestellungen bleiben konsistent.
Einige Bausteine tauchen in den meisten Geschäftssystemen auf:
order_status mit „Pending“, „Shipped“, „Cancelled“). Sie reduzieren Tippfehler und machen Änderungen kontrollierbar.OrderItems-Tabelle verbindet sie sauber.Mehr Normalisierung verbessert meistens die Konsistenz, kann aber mehr Tabellen und mehr Joins bedeuten. Übermäßige Normalisierung kann einige Abfragen schwerer und langsamer machen — Teams balancieren daher oft „saubere Struktur“ gegen praktische Anforderungen an Reporting und Performance aus.
Relationale Datenbanken speicherten Daten nicht nur ordentlich — sie machten sie in einer gemeinsamen Weise abfragbar. SQL (Structured Query Language) gab Unternehmen eine gemeinsame Sprache, um Antworten aus Tabellen zu ziehen, ohne für jeden neuen Report maßgeschneiderten Code zu schreiben.
Vor SQL bedeutete Abfragen oft herstellerspezifische Befehle oder einmalige Skripte, die nur wenige verstanden. Eine standardisierte Abfragesprache änderte das. Analysten, Entwickler und Reporting-Tools konnten alle mit derselben Grundsprache zur Datenbank sprechen.
Diese Standardisierung reduzierte Reibung zwischen Teams. Eine Abfrage aus der Buchhaltung konnte von der Betriebsabteilung wiederverwendet werden. Ein Reporting-Tool konnte mit minimalen Änderungen an unterschiedliche Datenbanken angeschlossen werden. Mit der Zeit wurden SQL-Kenntnisse über Jobs und Branchen übertragbar — das förderte die Verbreitung weiter.
SQL glänzt, weil es eng an reale Geschäftsfragen anknüpft:
Das sind im Kern Fragen zu Filtern, Sortieren, Gruppieren und Joinen — genau das, wofür SQL entworfen wurde.
Als SQL üblich wurde, entstand ein Ökosystem darum: BI-Dashboards, geplante Reports, Tabellenkalkulations-Connectoren und später Data Warehouses und ETL-Tools. Selbst wenn Firmen spezialisierte Analytics-Systeme hinzufügten, blieb SQL oft die Brücke zwischen operativen Daten und Entscheidungen — weil es die Sprache war, auf die alle zählen konnten.
Wenn sich eine Business-App „zuverlässig“ anfühlt, liegt das meist daran, dass die Datenbank Änderungen sicher verarbeiten kann — besonders wenn Geld, Lager und Kundenverpflichtungen im Spiel sind.
Stellen Sie sich eine Online-Bestellung vor:
Eine Transaktion behandelt all diese Updates als eine Einheit. Wenn etwas halb fehl schlägt (Zahlung abgelehnt, Systemabsturz, nicht vorrätig), kann die Datenbank zurückrollen und die Datensätze in einem sauberen, konsistenten Zustand belassen — kein „bezahlt aber keine Bestellung“, kein negativer Bestand, keine fehlende Rechnung.
Unternehmen vertrauen relationalen Datenbanken, weil die meisten ACID-Verhalten unterstützen — einfache Regeln, die Kerndaten verlässlich halten:
In Business-Software arbeiten viele Menschen gleichzeitig: Vertriebsmitarbeiter erstellen Angebote, Lagerpersonal kommissioniert, die Buchhaltung schließt Bücher, Support gibt Rückerstattungen aus. Ohne starke Nebenläufigkeitskontrolle könnten zwei Personen denselben letzten Artikel verkaufen oder sich gegenseitig Aktualisierungen überschreiben.
Datenintegrität ist das praktische Ergebnis: Finanzzahlen gleichen sich, Lagerbestände stimmen mit der Realität überein und Compliance-Reports haben nachvollziehbare Spuren, wer wann was getan hat. Deshalb sind RDBMS oft der Standard für „Systems of Record“.
Die meisten Business-Apps wollen nicht bei jedem Klick „Was ist dieses Quartal passiert?“ beantworten. Sie führen einfache, häufige Aufgaben aus: Rechnung erstellen, Versandstatus aktualisieren, Inventar reservieren oder Zahlung verbuchen. Dieses Muster heißt OLTP (Online Transaction Processing) — viele kleine Lese-/Schreibzugriffe von vielen Nutzern, den ganzen Tag.
Bei OLTP geht es um schnelle, konsistente Interaktionen: „Finde diesen Kunden“, „füge diese Position hinzu“, „markiere diese Bestellung als bezahlt“. Abfragen betreffen normalerweise nur kleine Datenbereiche und müssen schnell zurückliefern.
Analytics-Workloads sind anders: seltenere, aber schwere Abfragen — Aggregationen, lange Scans und Joins über große Zeiträume („Umsatz nach Region der letzten 18 Monate“). Viele Organisationen betreiben OLTP in einer RDBMS und Analytics in separaten Systemen oder Replikaten, um den Betrieb nicht zu verlangsamen.
Ein Index ist wie ein Inhaltsverzeichnis für eine Tabelle. Statt jede Zeile zu scannen, um customer_id = 123 zu finden, springt die Datenbank direkt zu den passenden Zeilen.
Der Nachteil: Indizes müssen gepflegt werden. Jeder Insert/Update aktualisiert möglicherweise mehrere Indizes, daher können zu viele Indizes Writes verlangsamen und Speicher erhöhen. Die Kunst ist, die Felder zu indexieren, nach denen am häufigsten gefiltert und gejoint wird.
Wenn Daten und Traffic wachsen, verlassen sich relationale Datenbanken auf Query Planning (effiziente Ausführungspläne), Constraints (die Daten gültig halten, sodass teure Bereinigungen seltener werden) und Betriebsmittel wie Backups und Point-in-Time-Recovery. Diese „langweiligen“ Features sind oft das, was tägliche Systeme bei Wachstum verlässlich hält.
Fehlende Indizes auf häufigen Filtern/Joins sind der Klassiker: Seiten, die bei 10k Zeilen schnell waren, werden bei 10M langsam.
Auch Anwendungsmuster spielen eine Rolle. N+1-Queries (eine Abfrage zum Auflisten, dann pro Element eine weitere Abfrage für Details) können die Datenbank überlasten. Und übermäßiges Joinen — viele Tabellen „nur zur Sicherheit“ verbinden — schafft unnötige Arbeit. Zweckgerichtete Abfragen und Messung mit realistischen Daten bringen meist die größten Verbesserungen.
ERP und CRM übernahmen relationale Datenbanken nicht nur, weil sie populär waren — sie brauchten die Art von Konsistenz, die Tabellen, Keys und Beziehungen durchsetzen.
Die meisten Kernprozesse sind strukturiert und wiederholbar: ein Kunde bestellt, eine Rechnung wird erstellt, Zahlung wird gebucht, Artikel werden kommissioniert, versendet und ggf. retourniert. Jeder Schritt lässt sich natürlich als Entität in Zeilen und Spalten beschreiben — Kunden, Produkte, Rechnungen, Zahlungen, Mitarbeiter, Standorte.
Relationales Design macht auch Quervergleiche einfach. Eine Rechnung kann nicht ohne Kunden existieren; eine Versandposition sollte sich auf ein echtes Produkt beziehen; eine Zahlung sollte einer Rechnung zugeordnet sein. ERP-Module (Finanzen, Einkauf, Inventar) und CRM-Funktionen (Accounts, Kontakte, Opportunities, Support-Fälle) stützen sich auf diese „dies muss zu jenem passen“-Regeln, um Datensätze über Teams hinweg abzustimmen.
Mit wachsender Organisation gab es zwei Optionen:
Beide Ansätze profitieren von klaren Schemata: Wenn Felder und Beziehungen explizit sind, lässt sich leichter Kunden-IDs, Produktcodes und Buchungsdimensionen synchronisieren, ohne ständig manuell korrigieren zu müssen.
Als ERP- und CRM-Anbieter auf relationale Grundlagen setzten, gewannen Unternehmen Portabilität bei Fähigkeiten. Einen Analysten mit SQL-Kenntnissen einzustellen — und Betriebsteams Standard-Reports beizubringen — war viel einfacher, als proprietäre Abfragewerkzeuge zu schulen.
Diese Standardisierung senkte langfristig die Kosten: weniger maßgeschneiderte Datenextrakte, wiederverwendbare Reporting-Muster und einfachere Übergaben zwischen Admins, Beratern und internen Teams. Für viele Unternehmen verwandelte das relationale Datenbanksystem von einer technischen Option in eine betriebliche Standardlösung.
Relationale Datenbanken gewannen nicht nur durch Modellierung — sie passten auch zur Art, wie Organisationen produktive Systeme betreiben. RDBMS-Produkte lieferten seit jeher vorhersehbare Betriebsroutinen: geplante Backups, Rollenverwaltung, Systemkataloge, Logs und Tools, die es praktikabel machten, Geschäftsdaten sicher und nachvollziehbar zu betreiben.
Eine Unternehmensdatenbank ist nur so vertrauenswürdig wie ihre Wiederherstellungsfähigkeit. RDBMS-Tools standardisierten Ansätze wie Full Backups, inkrementelle Backups und Point-in-Time-Recovery über Transaktionslogs. Teams konnten Wiederherstellungsprozeduren testen, dokumentieren und im Incident-Fall wiederholen — entscheidend für Gehaltsabrechnung, Rechnungswesen, Inventur und Kundendaten.
Monitoring wurde ebenfalls zu einem normalen Bestandteil des Betriebs: Speicherwachstum, langsame Abfragen, Lock-Contention und Replikationsgesundheit im Blick behalten. Wenn Probleme messbar sind, lassen sie sich auch managen.
Die meisten RDBMS-Plattformen machten Zugriffskontrolle zu einem Kernfeature. Anstatt ein geteiltes Passwort zu verwenden, können Admins Konten anlegen, in Rollen gruppieren und Berechtigungen auf Datenbank-, Tabellen- oder sogar Zeilenebene vergeben (abhängig vom System).
Zwei Governance-Basics sind besonders wichtig:
Diese Struktur unterstützt Compliance, ohne den Arbeitsalltag in dauernde Ausnahmeprozesse zu verwandeln.
RDBMS-Auditing — über Logs, Systemtabellen und eingebaute Audit-Funktionen — hilft zu beantworten: „Wer hat was wann geändert?“ Das ist nützlich für Troubleshooting, Sicherheitsuntersuchungen und regulierte Abläufe.
Bei Änderungen verlassen sich reife Teams auf wiederholbare Migrationen: scriptbasierte Schema-Änderungen in Versionskontrolle, geprüft und konsistent in allen Umgebungen angewendet. Kombiniert mit Freigaben und Rollback-Plänen reduziert das das Risiko von nächtlichen „Hotfixes“, die Reporting oder Integrationen stillschweigend beschädigen.
Betriebspraktiken entwickelten sich zu Mustern, die Unternehmen standardisieren konnten: Replikation für Redundanz, Failover für hohe Verfügbarkeit und Disaster-Recovery-Setups, die den Ausfall eines ganzen Rechenzentrums (oder einer Cloud-Region) annehmen. Diese Bausteine machten relationale Datenbanken zu einer sicheren Wahl für Kerndaten.
Cloud-Services ersetzten relationale Datenbanken nicht — sie veränderten, wie Teams sie betreiben. Statt Server zu kaufen, Datenbanksoftware zu installieren und Wartungsfenster zu planen, nutzen viele Firmen heute managed RDBMS-Angebote, bei denen der Provider viel von der Betriebsarbeit übernimmt.
Managed relationale Datenbanken bieten typischerweise automatisierte Backups, Point-in-Time-Restore (die DB auf einen Zeitpunkt vor einem Fehler zurücksetzen), eingebautes Patching und Monitoring. Für viele Business-Apps bedeutet das weniger nächtliche Recovery-Drills und planbarere Disaster-Pläne.
Skalierung wurde flexibler: CPU, Arbeitsspeicher und Speicher lassen sich oft per Einstellungen anpassen statt durch Hardware-Migration. Einige Plattformen unterstützen zudem Read-Scaling — Read-Replicas, damit Dashboards und umfangreiche Suchen das Order-Entry oder den Support nicht ausbremsen.
Replikation heißt, Kopien der Datenbank synchron zu halten. High Availability nutzt Replikation, um Ausfallzeiten zu reduzieren: Fällt die Primärdatenbank aus, kann eine Standby-Instanz übernehmen. Das ist wichtig für Systeme, die weiterhin Zahlungen annehmen, Sendungen erfassen oder Inventar aktualisieren müssen, auch wenn etwas kaputtgeht.
Wenn Unternehmen global Nutzer bedienen, wird Latenz zum echten Problem: Je weiter entfernt Kunden sind, desto langsamer fühlt sich jede Anfrage an. Gleichzeitig zerlegen Microservices und eventgetriebene Architekturen eine „große App“ in viele kleinere Dienste, jeweils mit eigenen Datenbedürfnissen und Release-Zyklen.
Viele Teams behalten das RDBMS als Quelle der Wahrheit für Kerndaten (Kunden, Rechnungen, Salden) und ergänzen andere Werkzeuge für spezielle Aufgaben — Suchmaschinen für schnellen Textsearch, Caches für Performance oder Analytics-Warehouses für umfangreiche Reports. So bleibt Datenintegrität dort, wo sie zählt, und zugleich werden Performance- und Integrationsbedürfnisse erfüllt. Für mehr zu Konsistenz siehe /blog/transactions-and-acid.
In der Praxis prägt das auch, wie Teams interne Tools bauen. Plattformen wie Koder.ai setzen auf den „relationalen Kern + moderne App“-Ansatz: man kann Web-Apps (React), Backends (Go) und PostgreSQL-gestützte Systeme of Record per Chat-Interface erzeugen — und mit Snapshots und Rollbacks sicher iterieren, wenn Schemata, Migrationen oder Workflows sich ändern.
Relationale Datenbanken sind nicht perfekt für jede Arbeitslast. Ihre Stärke — starke Struktur, Konsistenz und vorhersehbare Regeln — kann zu einer Einschränkung werden, wenn Daten oder Nutzungsmuster sich nicht sauber in Tabellen abbilden lassen.
Einige Szenarien sind weniger geeignet:
NoSQL-Systeme wurden populär, weil sie oft flexiblere Datenformen und einfachere horizontale Skalierung erlauben. Viele geben dafür einige Konsistenzgarantien oder reichhaltige Abfragemöglichkeiten zugunsten besserer Verteilbarkeit, schnellerer Writes oder einfacher Schema-Evolution auf — nützlich für bestimmte Produktbereiche, Analytics-Pipelines und volumenstarke Event-Erfassung.
Moderne Business-Stacks mischen Ansätze:
Wenn Sie Geld, Bestellungen, Inventar, Kundenkonten oder irgendetwas mit klaren Regeln und verlässlichen Updates verfolgen, ist ein RDBMS meist der sicherste Startpunkt. Nutzen Sie Alternativen dort, wo die Arbeitslast es wirklich erfordert — nicht nur, weil sie gerade im Trend liegen.
In Unternehmenssoftware braucht man eine einzige Quelle der Wahrheit für Dinge wie Kunden, Bestellungen, Rechnungen, Zahlungen und Lagerbestände.
Relationale Datenbanken sind darauf ausgelegt, Datensätze konsistent zu halten, während viele Nutzer und Prozesse gleichzeitig lesen und schreiben — sodass Berichte mit den operativen Daten übereinstimmen und „die Zahlen“ sich verrechnen lassen.
Eine relationale Datenbank speichert Daten in Tabellen (Zeilen und Spalten) mit Regeln.
Tabellen sind durch Keys verbunden (zum Beispiel referenziert Orders.CustomerID Customers.CustomerID), sodass die Datenbank verwandte Datensätze zuverlässig verknüpfen kann, ohne dieselben Details überall zu kopieren.
Dateibasierte Speicherung bricht zusammen, wenn mehrere Abteilungen dieselben Daten benötigen.
Häufige Probleme sind:
Ein Primary Key ist ein einzigartiger, stabiler Identifikator für eine Zeile (z. B. CustomerID).
Ein Foreign Key ist ein Feld, das auf einen Primary Key in einer anderen Tabelle zeigt (z. B. Orders.CustomerID → Customers.CustomerID).
Zusammen verhindern sie „mysteriöse Verknüpfungen“ und ermöglichen zuverlässige Joins.
Referentielle Integrität bedeutet, dass die Datenbank gültige Beziehungen erzwingt.
Praktisch hilft das, indem es:
Normalisierung heißt, Tabellen so zu gestalten, dass dieselbe Tatsache nicht mehrfach gespeichert wird.
Ein übliches Beispiel: Die Adresse eines Kunden wird einmal in Customers gespeichert und von Bestellungen per CustomerID referenziert. So behebt ein Update das Problem überall und reduziert die Drift zwischen „Kopien der Wahrheit“.
SQL machte Geschäftsdaten in einer standardisierten Form abfragbar, unabhängig vom Hersteller.
Es ist besonders geeignet für typische Fragen wie Filtern, Gruppieren und Joinen, etwa:
Eine Transaktion fasst mehrere Updates zu einer einzigen, alles-oder-nichts-Operation zusammen.
Im Bestellablauf umfasst das z. B. die Erstellung der Bestellung, die Verbuchung der Zahlung und das Reduzieren des Lagerbestands. Fällt etwas aus, kann die Datenbank zurückrollen, sodass es nicht zu „bezahlt, aber keine Bestellung“ oder zu negativem Lagerbestand kommt.
OLTP (Online Transaction Processing) beschreibt Muster vieler Business-Apps: viele kleine, schnelle Lese-/Schreibvorgänge von vielen Nutzern.
Relationale Datenbanken sind für OLTP optimiert—mit Indexen, Nebenläufigkeitskontrolle und vorhersehbarer Abfrageausführung—damit Kernprozesse (Kaufabschluss, Rechnungsstellung, Updates) unter Alltagslast zuverlässig bleiben.
Relationale Datenbanken haben Probleme bei:
Viele Teams nutzen Hybrid-Ansätze: RDBMS als System of Record und spezialisierte Stores (Search, Cache, Analytics) dort, wo sie sinnvoll sind.