⚖️ SQL vs NoSQL

📖 Definition

SQL (relationale Datenbanken) speichert Daten in tabellarischer Form mit strukturiertem Schema und manipuliert sie mit der SQL-Sprache. NoSQL (nicht-relationale Datenbanken) speichert Daten verschiedener Formen mit flexiblem Schema und ist vorteilhaft für horizontale Skalierung. Jedes hat Vor- und Nachteile und sollte entsprechend den Projektanforderungen gewählt werden.

🎯 Verständnis durch Analogie

Bibliothek vs Lager

SQL (Relationale DB) = Organisierte Bibliothek
├─ Alle Bücher sind an festgelegten Plätzen klassifiziert
├─ Präzise Informationen auf Katalogkarten verzeichnet
├─ Strenge Ausleihe-/Rückgaberegeln
└─ Leicht zu finden, aber wenig flexibel

NoSQL (Nicht-relationale DB) = Flexibles Lager
├─ Kann Gegenstände verschiedener Formen aufbewahren
├─ Schnelles Hinzufügen/Entfernen möglich
├─ Raumerweiterung einfach
└─ Flexibel, aber Organisation kann schwierig sein

Schulanwesenheitsliste vs Soziale Medien

SQL = Schulanwesenheitsliste
Schülertabelle:
┌────┬─────────┬─────┬────────┐
│ ID │  Name   │Alter│ Klasse │
├────┼─────────┼─────┼────────┤
│ 1  │ Hans    │ 15  │ 1A     │
│ 2  │ Anna    │ 15  │ 2A     │
└────┴─────────┴─────┴────────┘
- Alle Schüler haben dieselben Informationsfelder

NoSQL = Social-Media-Profil
Benutzer1: { name: "Hans", age: 15, hobbies: ["Lesen", "Spielen"] }
Benutzer2: { name: "Anna", city: "Berlin", job: "Schüler", pets: 2 }
- Jeder Benutzer kann unterschiedliche Informationen haben

⚙️ Funktionsweise

1. Vergleich der Datenstrukturen

-- SQL: Strukturierte Tabellen
users Tabelle
┌────┬─────────┬──────────────────┬─────┐
│ id │  name   │      email       │ age │
├────┼─────────┼──────────────────┼─────┤
│ 1  │ Hans    │ hans@mail.com    │ 25  │
│ 2  │ Anna    │ anna@mail.com    │ 30  │
└────┴─────────┴──────────────────┴─────┘

orders Tabelle
┌────┬─────────┬─────────────┬───────┐
│ id │ user_id │   product   │ price │
├────┼─────────┼─────────────┼───────┤
│ 1  │   1     │ Laptop      │ 1500  │
│ 2  │   1     │ Maus        │  30   │
└────┴─────────┴─────────────┴───────┘

// NoSQL: Flexible Dokumente
// MongoDB Beispiel
{
  _id: ObjectId("507f1f77bcf86cd799439011"),
  name: "Hans",
  email: "hans@mail.com",
  age: 25,
  orders: [                              // Verschachtelte Dokumente
    {
      product: "Laptop",
      price: 1500,
      date: "2024-01-15"
    },
    {
      product: "Maus",
      price: 30,
      date: "2024-01-20"
    }
  ],
  preferences: {                          // Verschiedene Strukturen
    theme: "dark",
    notifications: true
  }
}

2. Typen von NoSQL-Datenbanken

1. Document DB (Dokumentorientiert)
   └─ MongoDB, CouchDB
   └─ JSON-Dokumente speichern

2. Key-Value DB (Schlüssel-Wert)
   └─ Redis, DynamoDB
   └─ Schnelles Caching, Sitzungsspeicherung

3. Column-Family DB (Spaltenorientiert)
   └─ Cassandra, HBase
   └─ Großangelegte Datenanalyse

4. Graph DB (Graph)
   └─ Neo4j, Amazon Neptune
   └─ Beziehungszentrierte Daten (Soziale Netzwerke)

💡 Praktische Beispiele

SQL Beispiel (MySQL)

-- Tabellen erstellen (striktes Schema)
CREATE TABLE users (
  id INT PRIMARY KEY AUTO_INCREMENT,
  name VARCHAR(50) NOT NULL,
  email VARCHAR(100) UNIQUE NOT NULL,
  age INT,
  created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);

CREATE TABLE orders (
  id INT PRIMARY KEY AUTO_INCREMENT,
  user_id INT,
  product VARCHAR(100),
  price DECIMAL(10, 2),
  FOREIGN KEY (user_id) REFERENCES users(id)
);

-- Daten einfügen
INSERT INTO users (name, email, age)
VALUES ('Hans', 'hans@mail.com', 25);

-- Beziehungen mit JOIN abrufen
SELECT
  users.name,
  orders.product,
  orders.price
FROM users
INNER JOIN orders ON users.id = orders.user_id
WHERE users.name = 'Hans';

-- Transaktion (ACID-Garantie)
BEGIN TRANSACTION;
  UPDATE accounts SET balance = balance - 100 WHERE id = 1;
  UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;

NoSQL Beispiel (MongoDB)

// Kein Schema - freie Struktur
db.users.insertOne({
  name: "Hans",
  email: "hans@mail.com",
  age: 25,
  orders: [
    { product: "Laptop", price: 1500 },
    { product: "Maus", price: 30 }
  ]
});

// Andere Struktur möglich!
db.users.insertOne({
  name: "Anna",
  email: "anna@mail.com",
  hobbies: ["Lesen", "Reisen"],    // Andere Felder
  address: {                        // Verschachteltes Objekt
    city: "Berlin",
    zipcode: "10115"
  }
});

// Suche
db.users.find({ name: "Hans" });

// Suche in verschachteltem Dokument
db.users.find({
  "orders.product": "Laptop"
});

// Aktualisierung
db.users.updateOne(
  { name: "Hans" },
  {
    $set: { age: 26 },
    $push: {
      orders: { product: "Tastatur", price: 80 }
    }
  }
);

// Aggregation
db.users.aggregate([
  { $unwind: "$orders" },
  { $group: {
      _id: "$name",
      totalSpent: { $sum: "$orders.price" }
    }
  }
]);

SQL vs NoSQL in Node.js

// ============ SQL (MySQL) ============
const mysql = require('mysql2/promise');

const pool = mysql.createPool({
  host: 'localhost',
  user: 'root',
  password: 'password',
  database: 'myapp'
});

// Benutzer mit Bestellungen abrufen (JOIN erforderlich)
async function getUserWithOrders(userId) {
  const [rows] = await pool.execute(`
    SELECT
      users.name,
      users.email,
      orders.product,
      orders.price
    FROM users
    LEFT JOIN orders ON users.id = orders.user_id
    WHERE users.id = ?
  `, [userId]);

  return rows;
}

// ============ NoSQL (MongoDB) ============
const { MongoClient } = require('mongodb');

const client = new MongoClient('mongodb://localhost:27017');
const db = client.db('myapp');
const users = db.collection('users');

// Benutzer mit Bestellungen abrufen (JOIN nicht erforderlich - bereits enthalten)
async function getUserWithOrders(userId) {
  const user = await users.findOne({ _id: userId });
  // Bestellinformationen bereits in user.orders enthalten!
  return user;
}

Praktisches Beispiel: Blog-System

// ============ SQL-Ansatz ============
// Normalisierte Struktur
/*
posts Tabelle:
  id, title, content, author_id, created_at

comments Tabelle:
  id, post_id, user_id, content, created_at

tags Tabelle:
  id, name

post_tags Tabelle:
  post_id, tag_id
*/

// Beitrag + Kommentare + Tags abrufen → Mehrere JOINs erforderlich
SELECT
  posts.*,
  comments.content as comment,
  tags.name as tag
FROM posts
LEFT JOIN comments ON posts.id = comments.post_id
LEFT JOIN post_tags ON posts.id = post_tags.post_id
LEFT JOIN tags ON post_tags.tag_id = tags.id
WHERE posts.id = 1;

// ============ NoSQL-Ansatz ============
// Denormalisierte Struktur
{
  _id: ObjectId("..."),
  title: "MongoDB Einführung",
  content: "MongoDB ist...",
  author: {
    id: "user123",
    name: "Hans"
  },
  comments: [
    {
      user: { id: "user456", name: "Anna" },
      content: "Toller Artikel!",
      createdAt: "2024-01-15"
    }
  ],
  tags: ["Datenbank", "NoSQL"],
  createdAt: "2024-01-10"
}

// Alle Daten mit einer Abfrage abrufen!
db.posts.findOne({ _id: ObjectId("...") });

🤔 Häufig gestellte Fragen

F1. Welche sollte ich wählen?

A: Wählen Sie entsprechend den Projektmerkmalen:

✅ SQL wählen bei:
├─ Klare und feste Datenstruktur
├─ Komplexe Beziehungen und viele JOINs
├─ ACID-Transaktionen essentiell (Finanzen, E-Commerce)
├─ Datenintegrität wichtig
└─ Beispiele: Banksystem, Buchhaltungsprogramm, ERP

✅ NoSQL wählen bei:
├─ Flexible Datenstruktur
├─ Schnelle Lese-/Schreibgeschwindigkeit wichtig
├─ Horizontale Skalierung (Scale Out) erforderlich
├─ Verarbeitung großer Datenmengen
└─ Beispiele: Soziale Medien, IoT, Echtzeitanalyse, Logs

F2. Was sind die Hauptunterschiede?

A:

Merkmal	SQL	NoSQL
Datenstruktur	Tabellen (Zeilen, Spalten)	Dokumente, Schlüssel-Wert, Graphen usw.
Schema	Fest (strikt)	Flexibel (dynamisch)
Skalierung	Vertikal (Scale Up)	Horizontal (Scale Out)
Beziehungen	Verbindung durch JOIN	Verschachtelung oder Referenz
Transaktion	ACID-Garantie	Eventuelle Konsistenz (BASE)
Abfragen	SQL-Sprache	Je nach DB unterschiedlich
Beispiele	MySQL, PostgreSQL	MongoDB, Redis

// SQL: ACID
Atomicity    (Atomarität): Alles oder nichts
Consistency  (Konsistenz): Keine Regelverletzung
Isolation    (Isolation): Unabhängigkeit zwischen Transaktionen
Durability   (Dauerhaftigkeit): Permanente Speicherung

// NoSQL: BASE
Basically Available    (Grundsätzliche Verfügbarkeit)
Soft state            (Weicher Zustand)
Eventually consistent (Eventuelle Konsistenz)

F3. Unterschied in der Leistung?

A: Hängt vom Nutzungsmuster ab:

// SQL Vorteil: Komplexe Abfragen, JOINs
// Daten aus mehreren Tabellen kombinieren
SELECT u.name, p.title, c.content
FROM users u
JOIN posts p ON u.id = p.author_id
JOIN comments c ON p.id = c.post_id
WHERE u.age > 20
ORDER BY p.created_at DESC;
// → Leistungsstark und präzise, aber kann langsam sein

// NoSQL Vorteil: Schnelle Lese-/Schreibvorgänge
// Alle Informationen in einem Dokument
db.posts.find({ author_age: { $gt: 20 } })
  .sort({ created_at: -1 });
// → Sehr schnell, aber komplexe JOINs schwierig

// Benchmark-Beispiel
SQL:    10.000 Lesevorgänge/Sek  (komplexe JOINs)
NoSQL: 100.000 Lesevorgänge/Sek  (einfache Suche)

SQL:     5.000 Schreibvorgänge/Sek (Transaktionsgarantie)
NoSQL:  50.000 Schreibvorgänge/Sek (schnelles Schreiben)

F4. Kann ich beide zusammen verwenden?

A: Ja! Das nennt sich Polyglot Persistence:

// Beispiel: E-Commerce-System

// 1. SQL (MySQL) - Bestellungen, Zahlungen
// → ACID-Transaktionen essentiell
{
  orders: "MySQL",
  payments: "PostgreSQL",
  inventory: "MySQL"
}

// 2. NoSQL (MongoDB) - Produktkatalog
// → Flexible Attribute, schnelle Suche
{
  products: "MongoDB",
  reviews: "MongoDB"
}

// 3. NoSQL (Redis) - Caching, Sessions
// → Ultraschnelle Lese-/Schreibvorgänge
{
  cache: "Redis",
  sessions: "Redis",
  realtime: "Redis"
}

// 4. Graph DB (Neo4j) - Empfehlungssystem
// → Beziehungsbasierte Abfragen
{
  recommendations: "Neo4j",
  socialGraph: "Neo4j"
}

F5. Ist die Migration schwierig?

A: Mit strategischem Ansatz ist es möglich:

// SQL → NoSQL Migrationsstrategie

// 1. Hybrider Ansatz
// - Neue Funktionen in NoSQL
// - Bestehende Funktionen in SQL beibehalten

// 2. Schrittweise Migration
// Schritt 1: Beginnen mit schreibgeschützten Daten
// Schritt 2: Weniger kritische Funktionen
// Schritt 3: Kernfunktionen

// 3. Datensynchronisation
// - Change Data Capture (CDC)
// - Event Streaming (Kafka)

// Beispiel: Doppeltes Schreiben
async function createUser(userData) {
  // In SQL schreiben
  const sqlUser = await mysqlDB.insert(userData);

  // Auch in NoSQL schreiben (asynchron)
  await mongooDB.insertOne({
    ...userData,
    _id: sqlUser.id
  }).catch(err => {
    // SQL bleibt auch bei Fehler erhalten
    console.error('MongoDB-Synchronisation fehlgeschlagen:', err);
  });

  return sqlUser;
}

🎓 Nächste Schritte

Nachdem Sie SQL und NoSQL verstanden haben, lernen Sie:

1. Was ist eine Datenbank? - Grundkonzepte
2. Was ist Node.js? - Backend-Entwicklung
3. Was ist Docker? (Dokumentation in Arbeit) - Datenbank-Containerisierung

Praktische Übung

# ============ MySQL Praxis ============
# Installation
brew install mysql  # macOS

# Ausführung
mysql -u root -p

# Tabellen erstellen und Abfragen
CREATE DATABASE testdb;
USE testdb;
CREATE TABLE users (id INT, name VARCHAR(50));
INSERT INTO users VALUES (1, 'Hans');
SELECT * FROM users;

# ============ MongoDB Praxis ============
# Installation
brew tap mongodb/brew
brew install mongodb-community

# Ausführung
mongod --config /usr/local/etc/mongod.conf

# MongoDB Shell
mongosh

# Daten einfügen und suchen
use testdb
db.users.insertOne({ name: "Hans", age: 25 })
db.users.find()

🎬 Zusammenfassung

SQL und NoSQL haben jeweils ihre Vor- und Nachteile:

• SQL: Strukturierte Daten, ACID-Transaktionen, komplexe Beziehungen
• NoSQL: Flexibles Schema, schnelle Leistung, horizontale Skalierung
• Auswahlkriterien: Datenstruktur, Skalierbarkeit, Konsistenzanforderungen
• Polyglot: Bei Bedarf mehrere Datenbanken kombiniert verwenden

"Es gibt keine Silberkugel" - Wählen Sie die passende Datenbank für Ihr Projekt! ⚖️✨