NoSQL vs SQL: Die richtige Datenbank wählen

SQL und NoSQL haben unterschiedliche Stärken. Lernen Sie, wann welcher Datenbanktyp die richtige Wahl ist.

Grundlegender Vergleich

NoSQL-Typen

1. DOCUMENT STORES (MongoDB, CouchDB)
   ┌─────────────────────────────────────────┐
   │ { "_id": 1,                             │
   │   "name": "Max",                        │
   │   "orders": [                           │
   │     { "product": "Laptop", "price": 999 }│
   │   ]                                     │
   │ }                                       │
   └─────────────────────────────────────────┘
   → Flexible JSON-Dokumente
   → Gut für: Content Management, Kataloge, User-Profile

2. KEY-VALUE STORES (Redis, Memcached)
   ┌─────────────────┐
   │ user:1 → {...}  │
   │ session:abc → ..│
   │ cache:page:1 →  │
   └─────────────────┘
   → Schnellste Lese/Schreibzugriffe
   → Gut für: Caching, Sessions, Echtzeit-Daten

3. COLUMN STORES (Cassandra, HBase)
   ┌──────────────────────────────────────┐
   │ Row Key │ Column1 │ Column2 │ ...   │
   │─────────┼─────────┼─────────┼───────│
   │ user:1  │ name:Max│ age:30  │       │
   └──────────────────────────────────────┘
   → Optimiert für Schreiblast und Zeitreihen
   → Gut für: IoT, Logging, Analytics

4. GRAPH DATABASES (Neo4j, ArangoDB)
   ┌─────┐  FOLLOWS  ┌─────┐
   │Max  │──────────►│Anna │
   └──┬──┘           └──┬──┘
      │ LIKES           │ LIKES
      ▼                 ▼
   ┌─────┐           ┌─────┐
   │Post1│           │Post2│
   └─────┘           └─────┘
   → Beziehungen als First-Class-Citizen
   → Gut für: Social Networks, Empfehlungen, Fraud Detection

Wann SQL wählen?

✅ SQL ist besser wenn:

1. STRUKTURIERTE DATEN
   - Bekanntes, stabiles Schema
   - Daten passen gut in Tabellen
   - Starke Datenintegrität erforderlich

2. KOMPLEXE ABFRAGEN
   - Viele JOINs über mehrere Tabellen
   - Aggregationen (SUM, AVG, GROUP BY)
   - Ad-hoc Reporting und Analytics

3. TRANSAKTIONEN KRITISCH
   - Finanzanwendungen
   - Bestellsysteme
   - Alles wo ACID wichtig ist

4. BEZIEHUNGEN KOMPLEX
   - Many-to-Many Beziehungen
   - Normalisierte Datenstrukturen
   - Referentielle Integrität nötig

Beispiel-Anwendungen:
- E-Commerce (Bestellungen, Inventar)
- Finanz-Systeme (Transaktionen)
- ERP/CRM Systeme
- Content mit komplexen Beziehungen

Wann NoSQL wählen?

✅ NoSQL ist besser wenn:

1. FLEXIBLE/UNSTRUKTURIERTE DATEN
   - Schema ändert sich häufig
   - Unterschiedliche Attribute pro Dokument
   - Semi-strukturierte Daten (Logs, Events)

2. MASSIVE SKALIERUNG
   - Millionen von gleichzeitigen Usern
   - Petabytes an Daten
   - Geografisch verteilte Systeme

3. HOHE SCHREIBLAST
   - IoT-Sensordaten
   - Logging und Analytics
   - Real-time Streaming

4. ENTWICKLUNGSGESCHWINDIGKEIT
   - Schnelles Prototyping
   - Agile Entwicklung
   - Häufige Schema-Änderungen

Beispiel-Anwendungen:
- Social Media Feeds
- IoT-Plattformen
- Content Management
- Real-time Analytics
- Gaming (Leaderboards, Sessions)

Entscheidungsbaum

Brauchen Sie ACID-Transaktionen?
├── JA → SQL
└── NEIN ↓

Sind Ihre Daten stark vernetzt (viele Beziehungen)?
├── JA → SQL oder Graph-DB
└── NEIN ↓

Müssen Sie horizontal skalieren (sehr große Datenmengen)?
├── JA → NoSQL
└── NEIN ↓

Ist Ihr Schema stabil und bekannt?
├── JA → SQL
└── NEIN → Document Store (MongoDB)

Brauchen Sie extrem schnelle Key-Value Zugriffe?
├── JA → Redis/Memcached
└── NEIN ↓

Haben Sie Zeitreihendaten oder hohe Schreiblast?
├── JA → Column Store (Cassandra) oder Time-Series DB
└── NEIN ↓

Analysieren Sie Beziehungen/Verbindungen?
├── JA → Graph-DB (Neo4j)
└── NEIN → Document Store oder SQL

Praktische Beispiele

// E-Commerce: SQL (PostgreSQL)
// Komplexe Beziehungen, Transaktionen wichtig

-- Bestellung mit mehreren Produkten
BEGIN;
    INSERT INTO orders (user_id, total) VALUES (1, 150.00);

    INSERT INTO order_items (order_id, product_id, quantity)
    VALUES (LASTVAL(), 101, 2), (LASTVAL(), 102, 1);

    UPDATE products SET stock = stock - 2 WHERE id = 101;
    UPDATE products SET stock = stock - 1 WHERE id = 102;
COMMIT;

-- Komplexer Report
SELECT
    c.name AS category,
    COUNT(o.id) AS order_count,
    SUM(oi.quantity * p.price) AS revenue
FROM categories c
JOIN products p ON p.category_id = c.id
JOIN order_items oi ON oi.product_id = p.id
JOIN orders o ON o.id = oi.order_id
WHERE o.created_at >= '2024-01-01'
GROUP BY c.id
ORDER BY revenue DESC;

// Content Management: MongoDB
// Flexible Schemas, verschachtelte Dokumente

// Blog-Post mit eingebetteten Kommentaren
{
    "_id": ObjectId("..."),
    "title": "NoSQL vs SQL",
    "content": "...",
    "author": {
        "id": 123,
        "name": "Max"
    },
    "tags": ["database", "nosql", "sql"],
    "comments": [
        {
            "user": "Anna",
            "text": "Toller Artikel!",
            "likes": 5,
            "replies": [
                { "user": "Max", "text": "Danke!" }
            ]
        }
    ],
    "metadata": {
        "views": 1234,
        "shares": { "twitter": 50, "facebook": 30 }
    }
}

// Einfache Abfrage
db.posts.find({
    tags: "nosql",
    "metadata.views": { $gt: 1000 }
}).sort({ createdAt: -1 });

// Caching/Sessions: Redis

// Session speichern (Key-Value)
SET session:abc123 '{"userId":1,"cart":[101,102]}' EX 3600

// Leaderboard (Sorted Set)
ZADD leaderboard 1000 "player:1"
ZADD leaderboard 1500 "player:2"
ZREVRANGE leaderboard 0 9 WITHSCORES

// Rate Limiting
INCR api_calls:user:123
EXPIRE api_calls:user:123 60

// Social Network: Neo4j (Graph)

// Freunde von Freunden finden
MATCH (user:Person {name: 'Max'})-[:FOLLOWS]->()-[:FOLLOWS]->(suggestion)
WHERE NOT (user)-[:FOLLOWS]->(suggestion)
  AND suggestion <> user
RETURN suggestion.name, COUNT(*) as mutualFriends
ORDER BY mutualFriends DESC
LIMIT 10;

// Kürzester Pfad zwischen Nutzern
MATCH path = shortestPath(
    (a:Person {name: 'Max'})-[:FOLLOWS*]-(b:Person {name: 'Anna'})
)
RETURN path;

Polyglot Persistence

// Moderne Anwendungen nutzen oft mehrere Datenbanken

┌─────────────────────────────────────────────────────────┐
│                    E-COMMERCE APP                        │
├─────────────────────────────────────────────────────────┤
│                                                          │
│  PostgreSQL          MongoDB           Redis             │
│  ┌──────────┐       ┌──────────┐      ┌──────────┐     │
│  │ Orders   │       │ Products │      │ Sessions │     │
│  │ Users    │       │ Catalog  │      │ Cart     │     │
│  │ Payments │       │ Reviews  │      │ Cache    │     │
│  └──────────┘       └──────────┘      └──────────┘     │
│       ↑                  ↑                 ↑            │
│       │                  │                 │            │
│  Transaktionen     Flexible Schema   Schneller Zugriff  │
│                                                          │
│             Elasticsearch              Neo4j             │
│             ┌──────────┐           ┌──────────┐        │
│             │ Search   │           │ Recommend│        │
│             │ Index    │           │ -ations  │        │
│             └──────────┘           └──────────┘        │
│                  ↑                      ↑               │
│             Volltextsuche         Beziehungen           │
└─────────────────────────────────────────────────────────┘

Weitere Informationen

• 🐘 PostgreSQL vs MySQL
• 📊 SQL Indizes
• 🔄 Database Migrations