Die Datenbank-Evolution

Bevor es Datenbanken gab, waren Daten ein physisches Problem. Lochkarten, Magnetbänder, Aktenschränke – wer Informationen suchte, brauchte Zeit, Platz und Geduld.

Die Lochkarten-Ära

Herman Hollerith erfand 1890 die Lochkarte für die US-Volkszählung. Diese Technologie dominierte 70 Jahre lang:

• 80 Spalten pro Karte – daher heute noch 80 Zeichen in Terminals
• Sortiermaschinen – mechanische Datenverarbeitung
• "Do not fold, spindle or mutilate" – der erste Datenschutz-Hinweis

IBM 305 RAMAC (1956)

Die erste Festplatte der Welt: 50 Magnetscheiben, so groß wie zwei Kühlschränke, 5 MB Speicher. Kostenpunkt: 35.000 Dollar pro Jahr Miete.

Zum Vergleich: Ein USB-Stick heute speichert das 200.000-fache und kostet 10 Euro.

Das Problem der Flat Files

COBOL und andere Sprachen speicherten Daten in sequentiellen Dateien. Um Datensatz 47.293 zu finden, musste man durch 47.292 Datensätze "spulen".

Fun Fact: IBM nannte ihre erste Festplatte "Random Access" – weil man endlich direkt auf Daten zugreifen konnte, ohne zu spulen.

       IDENTIFICATION DIVISION.
       PROGRAM-ID. KUNDENLESEN.

       ENVIRONMENT DIVISION.
       INPUT-OUTPUT SECTION.
       FILE-CONTROL.
           SELECT KUNDEN-DATEI
           ASSIGN TO "KUNDEN.DAT"
           ORGANIZATION IS SEQUENTIAL.

       DATA DIVISION.
       FILE SECTION.
       FD KUNDEN-DATEI.
       01 KUNDEN-SATZ.
          05 KUNDEN-NR     PIC 9(5).
          05 KUNDEN-NAME   PIC X(30).
          05 KUNDEN-ORT    PIC X(20).

       * Sequentiell lesen - Datensatz für Datensatz
       * Keine Abfragen, kein Index, kein "WHERE"

Mit dem Apollo-Programm kam ein neues Problem: Die NASA musste Millionen von Bauteilen verwalten – hierarchisch strukturiert. Die Lösung: IMS (Information Management System).

IBM IMS (1966)

IMS war die erste echte Datenbank. Daten wurden in Baumstrukturen organisiert:

• Root Segment – die Wurzel (z.B. "Saturn V Rakete")
• Child Segments – Unterkategorien (Stufe 1, Stufe 2...)
• DL/I – Data Language/Interface zum Zugriff

Das Netzwerk-Modell (CODASYL)

1969 standardisierte CODASYL das Netzwerk-Modell: Datensätze konnten mehrere "Eltern" haben. Komplexer, aber flexibler.

Das Problem

Beide Modelle hatten einen fundamentalen Nachteil: Die Struktur der Daten war in der Anwendung fest verdrahtet. Jede Änderung am Schema bedeutete Änderungen am Code.

Fun Fact: IMS läuft heute noch – bei Banken, Versicherungen und Airlines. 50+ Jahre alter Code, der täglich Milliarden Transaktionen verarbeitet.

* IMS Hierarchische Struktur

        SATURN-V-RAKETE (Root)
        ├── STUFE-1
        │   ├── F1-TRIEBWERK-1
        │   ├── F1-TRIEBWERK-2
        │   └── TREIBSTOFFTANK
        ├── STUFE-2
        │   ├── J2-TRIEBWERK-1
        │   └── J2-TRIEBWERK-2
        └── STUFE-3
            └── J2-TRIEBWERK

* DL/I Zugriff (pseudo)
GU    RAKETE (RAKETE-ID = 'SATURN-V')
GNP   STUFE  (STUFE-NR = 1)
GNP   TRIEBWERK

* Navigation durch die Hierarchie
* Keine Ad-hoc Abfragen möglich
* "Finde alle Triebwerke" = Code schreiben

1970 veröffentlichte Edgar F. Codd bei IBM ein Paper, das alles veränderte: "A Relational Model of Data for Large Shared Data Banks".

Codds revolutionäre Idee

Statt Bäume und Netzwerke: Tabellen. Einfache, mathematisch fundierte Tabellen mit Zeilen und Spalten. Beziehungen zwischen Daten durch gemeinsame Werte, nicht durch Zeiger.

• Datenunabhängigkeit – Schema ändern ohne Code ändern
• Deklarative Abfragen – sag was du willst, nicht wie
• Mathematische Basis – Mengenlehre und Prädikatenlogik

SQL wird geboren (1974)

Donald Chamberlin und Raymond Boyce bei IBM entwickelten SEQUEL (später SQL) – eine Sprache, die sich wie Englisch liest.

Die Ironie bei IBM

Codd arbeitete bei IBM – aber IBM ignorierte ihn erst. Sie hatten zu viel in IMS investiert. Erst als Oracle (1979) und andere SQL-Datenbanken auf den Markt brachten, zog IBM mit DB2 (1983) nach.

Fun Fact: Oracle's erste Version lief auf einem PDP-11 mit 128 KB RAM. Larry Ellison verkaufte sie an die CIA.

-- SQL: Die deklarative Revolution
-- "Sag was du willst, nicht wie"

-- Statt Navigation durch Hierarchien:
SELECT
    k.name,
    k.email,
    b.datum,
    b.betrag
FROM kunden k
JOIN bestellungen b ON k.id = b.kunden_id
WHERE b.datum >= '2024-01-01'
  AND b.betrag > 1000
ORDER BY b.betrag DESC;

-- Vergleich mit hierarchischem Zugriff:
-- IMS: 50 Zeilen Code
-- SQL: 8 Zeilen

-- Die Datenbank findet den optimalen Weg.
-- Der Programmierer beschreibt nur das Ziel.

In den 90ern wurden Datenbanken demokratisiert. Was vorher Mainframes und Großkonzerne brauchte, lief plötzlich auf PCs.

Die Desktop-Datenbanken

• dBASE (1979) – der Pionier für PCs
• FoxPro (1984) – schnell und beliebt
• Microsoft Access (1992) – Datenbanken für "normale Menschen"
• FileMaker (1985) – der Mac-Favorit

Die Open-Source-Revolution

1995 erschien MySQL – kostenlos, schnell, gut genug. MySQL wurde zum Rückgrat des frühen Web: LAMP-Stack (Linux, Apache, MySQL, PHP).

PostgreSQL (1996) ging einen anderen Weg: Nicht nur kostenlos, sondern auch feature-reich. JSON, Volltextsuche, Geo-Daten – PostgreSQL wurde zum "Enterprise-Killer".

Das Web verändert alles

Mit dem Web explodierten die Anforderungen:

• Millionen gleichzeitige User
• Globale Verfügbarkeit (24/7)
• Flexible Datenstrukturen (nicht alles passt in Tabellen)

Fun Fact: MySQL wurde für 1 Milliarde Dollar von Sun Microsystems gekauft – Sun wurde kurz darauf von Oracle übernommen. Ironie der Geschichte.

-- MySQL - Der LAMP-Stack Klassiker

-- Typische Web-Anwendung der 2000er
CREATE TABLE users (
    id INT AUTO_INCREMENT PRIMARY KEY,
    username VARCHAR(50) NOT NULL UNIQUE,
    email VARCHAR(100) NOT NULL,
    password_hash CHAR(60) NOT NULL,
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE posts (
    id INT AUTO_INCREMENT PRIMARY KEY,
    user_id INT NOT NULL,
    title VARCHAR(200) NOT NULL,
    content TEXT,
    FOREIGN KEY (user_id) REFERENCES users(id)
);

-- PHP + MySQL = Das Web der 2000er
-- SELECT * FROM posts
-- WHERE user_id = $_GET['id']
-- (Bitte nicht so - SQL Injection!)

2009 erschien MongoDB – und mit ihr der Begriff NoSQL. Die Idee: Nicht jedes Problem braucht Tabellen.

Warum NoSQL?

Google, Facebook, Amazon hatten Probleme, die SQL nicht lösen konnte:

• Skalierung – Millionen Requests pro Sekunde
• Flexible Schemas – JSON statt starrer Tabellen
• Verteilung – Daten über Kontinente verteilt

Die NoSQL-Familie

• MongoDB (2009) – Dokumente (JSON)
• Redis (2009) – Key-Value (Cache)
• Cassandra (2008) – Wide-Column (Facebook)
• Neo4j (2007) – Graphen (Beziehungen)

Die Cloud-Ära

Heute muss niemand mehr Datenbanken installieren:

• AWS RDS / Aurora – Managed SQL
• MongoDB Atlas – Managed NoSQL
• PlanetScale – Serverless MySQL
• Supabase – PostgreSQL as a Service

Von einer Tonne Hardware für 5 MB zu unbegrenztem Speicher in der Cloud – in 70 Jahren. Edgar Codd hätte gestaunt.

// MongoDB - Dokumente statt Tabellen

// Flexibles Schema - kein CREATE TABLE nötig
const user = {
    _id: ObjectId("507f1f77bcf86cd799439011"),
    name: "Max Mustermann",
    email: "max@example.com",
    // Verschachtelte Objekte - in SQL: 3 Tabellen
    address: {
        street: "Musterstraße 1",
        city: "Berlin",
        zip: "10115"
    },
    // Arrays - in SQL: separate Tabelle + JOIN
    orders: [
        { product: "Laptop", price: 999, date: new Date() },
        { product: "Mouse", price: 29, date: new Date() }
    ]
};

// Abfrage - auch mit verschachtelten Daten
db.users.find({
    "address.city": "Berlin",
    "orders.price": { $gt: 500 }
});

// 1956: 5 MB auf einer Tonne Hardware
// 2024: Unbegrenzt in der Cloud