SQL (relational): Strukturierte Daten in Tabellen mit festem Schema, ACID-Transaktionen, komplexe JOINs möglich. Ideal für transaktionale Anwendungen (Banking, E-Commerce).

NoSQL (nicht-relational): Flexible Schemata, horizontale Skalierung, verschiedene Modelle (Dokument, Key-Value, Column, Graph). Ideal für Big Data, Echtzeit-Anwendungen und unstrukturierte Daten.

Beispiele: SQL: MySQL, PostgreSQL, MSSQL | NoSQL: MongoDB, Redis, Cassandra

Die Wahl hängt von Ihren Anforderungen ab:

• Transaktionale Anwendungen (E-Commerce, Banking): SQL (PostgreSQL, MySQL)
• Content Management, Blogs: SQL (MySQL) oder NoSQL (MongoDB)
• Real-Time Analytics, IoT: NoSQL (Cassandra, InfluxDB)
• Caching, Session-Storage: Key-Value (Redis, Memcached)
• Soziale Netzwerke, Beziehungen: Graph-Datenbank (Neo4j)
• Big Data, Data Lakes: Hadoop, Spark, S3

Das CAP-Theorem besagt, dass ein verteiltes Datenbanksystem nur zwei der drei Eigenschaften gleichzeitig garantieren kann:

• C (Consistency): Alle Knoten sehen zur gleichen Zeit dieselben Daten
• A (Availability): Jede Anfrage erhält eine Antwort (auch bei Fehlern)
• P (Partition Tolerance): Das System funktioniert auch bei Netzwerk-Partitionen

Beispiele: SQL-Datenbanken: CA (strenge Konsistenz) | NoSQL-Datenbanken: AP oder CP (verfügbar oder konsistent)

Indexing ist eine Datenstruktur, die schnelle Abfragen ermöglicht – ähnlich wie ein Buchindex. Ohne Index muss die Datenbank jede Zeile durchsuchen (Full Table Scan), was bei großen Tabellen sehr langsam ist.

Vorteile: Deutlich schnellere SELECT-Abfragen, besonders bei WHERE, JOIN und ORDER BY

Nachteile: Mehr Speicherplatz, langsamere INSERT/UPDATE/DELETE (Index muss aktualisiert werden)

Best Practice: Indizes auf häufig abgefragte Spalten setzen, aber nicht übertreiben!

Replizierung: Kopien derselben Daten auf mehreren Servern für hohe Verfügbarkeit und Leseskalierung. Alle Replikate enthalten dieselben Daten.

Sharding: Aufteilung der Daten auf mehrere Server (Shards). Jeder Shard enthält einen Teil der Daten. Ermöglicht horizontale Skalierung für Schreiboperationen und große Datenmengen.

Kombination: Oft werden beide Techniken kombiniert – Replizierung für Verfügbarkeit, Sharding für Skalierung.

Normalisierung ist ein Prozess zur Reduzierung von Datenredundanz und Verbesserung der Datenintegrität. Es gibt mehrere Normalformen:

• 1NF: Atomare Werte, keine wiederholten Gruppen
• 2NF: 1NF + keine partiellen Abhängigkeiten
• 3NF: 2NF + keine transitiven Abhängigkeiten
• BCNF: Strengere Version von 3NF

Vorteile: Weniger Redundanz, bessere Konsistenz, einfachere Wartung

Nachteile: Mehr JOINs nötig, kann Performance beeinträchtigen (manchmal Denormalisierung besser)

ACID definiert die Eigenschaften von Datenbank-Transaktionen:

• A (Atomicity): Transaktionen sind atomar – entweder ganz oder gar nicht
• C (Consistency): Transaktionen bringen die DB von einem konsistenten Zustand in einen anderen
• I (Isolation): Gleichzeitige Transaktionen beeinflussen sich nicht gegenseitig
• D (Durability): Nach Commit sind Änderungen permanent (auch bei Stromausfall)

Wichtig für: Banking, E-Commerce, Buchhaltung – überall wo Datenintegrität kritisch ist

Best Practices für Datenbank-Sicherheit:

• Starke Passwörter: Komplexe Passwörter für DB-Admins
• Least Privilege: Minimale Berechtigungen für Anwendungen
• Verschlüsselung: Daten in Transit (TLS) und at Rest (AES-256)
• Firewall: Nur autorisierte IPs auf DB-Port
• Regelmäßige Backups: 3-2-1-Regel (3 Kopien, 2 Medien, 1 extern)
• Auditing: Alle Zugriffe loggen und überwachen
• Updates: DB-Software und Patches aktuell halten
• SQL Injection Schutz: Prepared Statements verwenden

Data Lake: Speicher für rohe, unstrukturierte oder semi-strukturierte Daten in ihrem nativen Format. Schema-on-Read – Struktur wird erst bei der Analyse angewendet.

Data Warehouse: Speicher für strukturierte, verarbeitete Daten mit festem Schema. Schema-on-Write – Struktur wird vor dem Speichern definiert.

Beispiele: Data Lake: AWS S3, Azure Data Lake | Data Warehouse: Snowflake, BigQuery, Redshift

Verwendung: Data Lake für Big Data Analytics und Machine Learning | Data Warehouse für Business Intelligence und Reporting

Skalierungsstrategien:

• Vertikal (Scale Up): Mehr CPU, RAM, schnellere SSDs – einfach, aber begrenzt
• Horizontal (Scale Out): Mehr Server hinzufügen – komplexer, aber unbegrenzt skalierbar
• Replizierung: Read-Replikate für Leselast verteilen
• Sharding: Daten auf mehrere Server aufteilen
• Partitionierung: Große Tabellen in kleinere Teile aufteilen
• Caching: Häufig abgefragte Daten im Cache halten (Redis, Memcached)
• Connection Pooling: Wiederverwendung von Datenbankverbindungen

Empfehlung: Beginnen Sie mit vertikaler Skalierung, dann Replizierung, dann Sharding wenn nötig.