SQL-Datenbanken

KAPITEL 06 · DATENBANKEN

SQL-Datenbanken

Relationale Datenbanksysteme (RDBMS) sind das Rückgrat der meisten Enterprise-Anwendungen. Erfahren Sie alles über SQL-Syntax, ACID-Prinzipien, Normalisierung, Joins, Indizes und die wichtigsten Datenbank-Systeme im Vergleich.

RDBMS ACID SQL-Syntax Joins Performance

Inhaltsverzeichnis

Schnellübersicht

Auf dieser Seite lernen Sie alles über SQL-Datenbanken:

  • Definition: Was sind relationale Datenbanken und SQL?
  • RDBMS-Systeme: MySQL, PostgreSQL, SQL Server, Oracle, SQLite, MariaDB
  • SQL-Kategorien: DDL, DML, DQL, DCL, TCL
  • ACID-Prinzipien: Atomicity, Consistency, Isolation, Durability
  • Normalisierung: 1NF, 2NF, 3NF, BCNF
  • Joins: INNER, LEFT, RIGHT, FULL, CROSS, SELF
  • Indizes: Performance-Optimierung
  • Best Practices: Design, Performance, Sicherheit

1. Was sind SQL-Datenbanken?

Definition

SQL-Datenbanken (auch relationale Datenbanken oder RDBMS - Relational Database Management Systems) sind Datenbanksysteme, die Daten in strukturierten Tabellen mit Zeilen (Records) und Spalten (Attributes) speichern. Die Tabellen sind über Beziehungen (Relations) miteinander verbunden, typischerweise über Primär- und Fremdschlüssel.

SQL (Structured Query Language) ist die standardisierte Abfragesprache für relationale Datenbanken. Mit SQL können Sie Tabellen erstellen, Daten einfügen, aktualisieren, löschen und komplexe Abfragen durchführen. SQL wurde in den 1970er Jahren bei IBM entwickelt und ist bis heute der Industriestandard.

Typische Einsatzgebiete: Unternehmensanwendungen (ERP, CRM), E-Commerce-Systeme, Banken und Finanzdienstleister, Content-Management-Systeme, Buchhaltungssysteme, Patientenverwaltung und überall dort, wo Datenkonsistenz und Transaktionssicherheit entscheidend sind.

SQL vs. NoSQL – Wann welches System?

  • SQL-Datenbanken: Strukturierte Daten, klare Beziehungen, ACID-Transaktionen, komplexe Joins
  • NoSQL-Datenbanken: Unstrukturierte/semi-strukturierte Daten, hohe Skalierbarkeit, flexible Schemata
  • SQL-Beispiele: MySQL, PostgreSQL, SQL Server, Oracle
  • NoSQL-Beispiele: MongoDB, Cassandra, Redis, Elasticsearch

2. Die wichtigsten RDBMS-Systeme

Ein Überblick über die führenden relationalen Datenbanksysteme und ihre typischen Einsatzgebiete.

MySQL

Das beliebteste Open-Source-RDBMS

MySQL ist das weltweit am häufigsten eingesetzte Open-Source-Datenbanksystem. Es ist Teil des LAMP-Stacks und die Basis vieler Webanwendungen.

  • Sehr hohe Performance
  • Große Community & Dokumentation
  • Replikation & Clustering
  • Viele Storage Engines (InnoDB, MyISAM)
  • Ideal für Webanwendungen
GPL / Commercial Web, CMS, E-Commerce

PostgreSQL

Das fortschrittlichste Open-Source-RDBMS

PostgreSQL ist bekannt für seine Zuverlässigkeit, Datenintegrität und fortschrittlichen Features. Es ist die erste Wahl für komplexe Anwendungen.

  • ACID-konform & zuverlässig
  • Erweiterte Datentypen (JSON, Arrays, GIS)
  • Stored Procedures in vielen Sprachen
  • Volltextsuche & Triggers
  • Ideal für Data Warehousing
PostgreSQL License Enterprise, GIS, Analytics

SQL Server

Microsofts Enterprise-Datenbank

Microsoft SQL Server ist die führende Datenbank im Windows-Ökosystem. Tiefe Integration mit Azure, .NET und Power BI.

  • Tiefe Windows-Integration
  • T-SQL (Transact-SQL)
  • Business Intelligence (SSRS, SSIS)
  • Azure-Integration
  • Enterprise-Support
Commercial Enterprise, .NET, BI

Oracle Database

Die Enterprise-Lösung für Großkonzerne

Oracle ist die weltweit führende kommerzielle Datenbank. Sie wird in Großunternehmen für geschäftskritische Systeme eingesetzt.

  • Höchste Skalierbarkeit
  • Advanced Features (Partitioning, RAC)
  • PL/SQL Stored Procedures
  • Enterprise-Support
  • Ideal für Großunternehmen
Commercial Banken, Konzerne, ERP

SQLite

Die eingebettete Serverless-Datenbank

SQLite ist eine serverlose, dateibasierte Datenbank. Sie wird direkt in Anwendungen eingebettet und benötigt keinen separaten Server.

  • Keine Server-Konfiguration
  • Einzelne Datei (portabel)
  • Extrem leichtgewichtig
  • Zero-Configuration
  • Ideal für Mobile & Embedded
Public Domain Mobile, Embedded, Testing

MariaDB

Der MySQL-Fork mit Community-Fokus

MariaDB ist ein Fork von MySQL, gegründet vom ursprünglichen MySQL-Entwickler. Er bietet verbesserte Performance und mehr Features.

  • Drop-in Replacement für MySQL
  • Bessere Performance
  • Mehr Storage Engines
  • Community-getrieben
  • Galera Cluster (Multi-Master)
GPL Web, Cloud, Cluster

3. SQL-Kategorien

SQL-Befehle werden in fünf Kategorien unterteilt, je nachdem, welche Operationen sie ausführen.

DDL – Data Definition Language

Definiert die Struktur der Datenbank: Tabellen, Indizes, Views und Schemata.

CREATE, ALTER, DROP, TRUNCATE, RENAME

DML – Data Manipulation Language

Manipuliert die Daten in den Tabellen: Einfügen, Aktualisieren, Löschen.

INSERT, UPDATE, DELETE, MERGE

DQL – Data Query Language

Abfragen von Daten aus den Tabellen. Die wichtigste Kategorie für Entwickler.

SELECT

DCL – Data Control Language

Steuert den Zugriff auf Daten: Berechtigungen und Rechte verwalten.

GRANT, REVOKE

TCL – Transaction Control Language

Verwaltet Transaktionen: Speichern, Rückgängig machen, Savepoints setzen.

COMMIT, ROLLBACK, SAVEPOINT

Beispiel: Alle Kategorien in Aktion

SQL -- DDL: Tabelle erstellen CREATE TABLE users ( id INT PRIMARY KEY, username VARCHAR(50), email VARCHAR(100) ); -- DML: Daten einfügen INSERT INTO users VALUES (1, 'max', 'max@example.com'); -- DQL: Daten abfragen SELECT * FROM users WHERE id = 1; -- DML: Daten aktualisieren UPDATE users SET email = 'new@example.com' WHERE id = 1; -- TCL: Transaktion abschließen COMMIT; -- DCL: Berechtigung erteilen GRANT SELECT ON users TO 'readonly_user';

4. ACID-Prinzipien

ACID ist ein Akronym für die vier grundlegenden Eigenschaften, die zuverlässige Datenbanktransaktionen garantieren. Sie sind der Grund, warum SQL-Datenbanken in geschäftskritischen Systemen eingesetzt werden.

Die 4 ACID-Prinzipien

A
Atomicity (Atomarität)

Eine Transaktion wird entweder vollständig oder gar nicht ausgeführt. Wenn ein Teil fehlschlägt, wird die gesamte Transaktion zurückgesetzt (Rollback).

C
Consistency (Konsistenz)

Die Datenbank befindet sich vor und nach jeder Transaktion in einem konsistenten Zustand. Alle Integritätsregeln werden eingehalten.

I
Isolation (Isolierung)

Parallele Transaktionen beeinflussen sich nicht gegenseitig. Jede Transaktion läuft so ab, als wäre sie die einzige.

D
Durability (Dauerhaftigkeit)

Eine abgeschlossene Transaktion (Commit) ist permanent gespeichert – auch bei Systemausfall oder Stromausfall.

ACID-Beispiel: Banküberweisung

Eine Überweisung von Konto A (1000 €) nach Konto B (500 €) über 200 €:

  • Atomicity: Wenn das Abbuchen von A funktioniert, aber das Gutschreiben auf B fehlschlägt, wird das Abbuchen rückgängig gemacht.
  • Consistency: Die Summe aller Kontostände bleibt gleich (1500 €).
  • Isolation: Eine parallele Überweisung sieht keine Zwischenergebnisse.
  • Durability: Nach dem Commit ist die Überweisung permanent gespeichert.

5. Normalisierung

Normalisierung ist der Prozess, eine Datenbank so zu strukturieren, dass Redundanzen minimiert und Anomalien vermieden werden. Es gibt verschiedene Normalformen (NF), die schrittweise angewendet werden.

Die Normalformen im Überblick

1NF
Erste Normalform (1NF)

Alle Attribute enthalten nur atomare (unteilbare) Werte. Keine Mengen oder Listen in einer Zelle. Jede Spalte enthält nur einen Wert.

❌ Falsch: telefon = "030-123, 030-456"
✅ Richtig: Separate Zeilen oder separate Spalten für jede Telefonnummer
2NF
Zweite Normalform (2NF)

Die Tabelle ist in 1NF und alle Nicht-Schlüssel-Attribute sind vollständig vom Primärschlüssel abhängig (nicht nur von einem Teil eines zusammengesetzten Schlüssels).

❌ Falsch: bestellung(produkt_id, kunde_id, produkt_name)
✅ Richtig: produkt_name in eigene Produkte-Tabelle auslagern
3NF
Dritte Normalform (3NF)

Die Tabelle ist in 2NF und es gibt keine transitiven Abhängigkeiten. Nicht-Schlüssel-Attribute hängen nicht voneinander ab.

❌ Falsch: kunde(plz, ort) – ort hängt von plz ab
✅ Richtig: Separate plz_orte-Tabelle mit plz und ort
BCNF
Boyce-Codd-Normalform (BCNF)

Eine stärkere Form der 3NF. Jede Determinante (Attribut, das andere Attribute bestimmt) muss ein Kandidatenschlüssel sein.

BCNF behebt spezielle Anomalien, die in der 3NF noch auftreten können. In der Praxis reicht meist 3NF für die meisten Anwendungen.

Normalisierung vs. Denormalisierung

  • Normalisierung: Reduziert Redundanzen, verbessert Datenkonsistenz, aber kann Performance durch viele Joins reduzieren
  • Denormalisierung: Fügt gezielt Redundanzen hinzu, um Performance zu verbessern (weniger Joins)
  • Empfehlung: Zuerst normalisieren (3NF), dann bei Performance-Problemen gezielt denormalisieren
  • Data Warehouses: Oft denormalisiert für schnelle Lesezugriffe (Star-Schema, Snowflake-Schema)

6. SQL Joins

Joins verbinden Daten aus mehreren Tabellen basierend auf gemeinsamen Spalten (meist Primär- und Fremdschlüssel). Sie sind die Grundlage für komplexe Abfragen in relationalen Datenbanken.

Die 6 wichtigsten Join-Typen

INNER JOIN
SELECT * FROM users
INNER JOIN orders
ON users.id = orders.user_id;

Gibt nur Zeilen zurück, die in beiden Tabellen übereinstimmen. Der am häufigsten verwendete Join-Typ.

LEFT JOIN
SELECT * FROM users
LEFT JOIN orders
ON users.id = orders.user_id;

Gibt alle Zeilen der linken Tabelle zurück, auch wenn keine Übereinstimmung in der rechten Tabelle existiert.

RIGHT JOIN
SELECT * FROM users
RIGHT JOIN orders
ON users.id = orders.user_id;

Gibt alle Zeilen der rechten Tabelle zurück, auch wenn keine Übereinstimmung in der linken Tabelle existiert.

FULL OUTER JOIN
SELECT * FROM users
FULL OUTER JOIN orders
ON users.id = orders.user_id;

Gibt alle Zeilen aus beiden Tabellen zurück, auch wenn keine Übereinstimmung existiert.

CROSS JOIN
SELECT * FROM users
CROSS JOIN products;

Erzeugt das kartesische Produkt – jede Zeile der ersten Tabelle wird mit jeder Zeile der zweiten Tabelle kombiniert.

SELF JOIN
SELECT a.name, b.name AS manager
FROM employees a
JOIN employees b ON a.manager_id = b.id;

Eine Tabelle wird mit sich selbst gejoint. Nützlich für hierarchische Daten (Mitarbeiter-Chef-Beziehungen).

Join-Performance-Tipps

  • Indizes auf Join-Spalten: Immer Indizes auf Fremdschlüssel-Spalten erstellen
  • Selektive Joins: WHERE-Klausel so früh wie möglich anwenden
  • EXPLAIN analysieren: Query Execution Plan prüfen (EXPLAIN SELECT...)
  • Joins minimieren: Zu viele Joins können Performance-Probleme verursachen
  • UNION vs. JOIN: UNION für vertikale Kombination, JOIN für horizontale

7. Indizes & Performance

Indizes sind das wichtigste Werkzeug zur Performance-Optimierung von Datenbanken. Sie beschleunigen SELECT-Abfragen dramatisch, verlangsamen aber INSERT/UPDATE/DELETE-Operationen leicht.

Wie funktionieren Indizes?

Ein Index ist wie das Inhaltsverzeichnis eines Buches: Statt jede Seite durchzublättern (Full Table Scan), schaut die Datenbank zuerst ins Inhaltsverzeichnis und springt direkt zur richtigen Stelle. Dies reduziert die Zugriffszeit von Sekundenbruchteilen auf Mikrosekunden.

Primary Key Index

Automatisch erstellt, eindeutig, nicht nullbar. Die wichtigste Form des Index. Garantiert Datenintegrität.

Unique Index

Stellt sicher, dass alle Werte in einer Spalte eindeutig sind. Wird oft für E-Mail-Adressen oder Benutzernamen verwendet.

B-Tree Index

Der Standard-Index-Typ. Ideal für Bereichsabfragen (WHERE id > 100), Sortierung und Gleichheitsabfragen.

Hash Index

Sehr schnell für exakte Gleichheitsabfragen (WHERE email = '...'), aber nicht für Bereichsabfragen.

Full-Text Index

Für Volltextsuche in Textspalten. Ermöglicht komplexe Textabfragen wie "finde alle Artikel mit 'Datenbank'".

Composite Index

Index über mehrere Spalten. Wichtig: Reihenfolge der Spalten beeinflusst Performance (Leftmost Prefix Rule).

Index-Best-Practices

  • Indizes auf WHERE-Spalten: Spalten, die oft in WHERE-Klauseln verwendet werden
  • Indizes auf Join-Spalten: Fremdschlüssel immer indizieren
  • Indizes auf ORDER BY-Spalten: Für schnelleres Sortieren
  • Nicht zu viele Indizes: Jeder Index verlangsamt Schreiboperationen
  • EXPLAIN nutzen: Query Execution Plan analysieren, um fehlende Indizes zu finden
  • Regelmäßige Wartung: Indizes neu aufbauen (REINDEX), Statistiken aktualisieren

8. RDBMS-Vergleich

Ein detaillierter Vergleich der wichtigsten relationalen Datenbanksysteme.

Datenbank Lizenz ACID Replikation Skalierung Typische Anwendung
MySQL GPL / Commercial ✅ Ja (InnoDB) Master-Slave, Group Mittel bis Hoch Web, CMS, E-Commerce
PostgreSQL PostgreSQL License ✅ Ja Streaming, Logical Hoch Enterprise, GIS, Analytics
SQL Server Commercial ✅ Ja Always On, Mirroring Sehr Hoch Enterprise, .NET, BI
Oracle Commercial ✅ Ja RAC, Data Guard Extrem Hoch Banken, Konzerne, ERP
SQLite Public Domain ✅ Ja Keine Niedrig Mobile, Embedded, Testing
MariaDB GPL ✅ Ja Galera, Master-Slave Hoch Web, Cloud, Cluster

9. Best Practices

Datenbank-Design

  • Zuerst normalisieren (3NF), dann gezielt denormalisieren
  • Bedeutungsvolle Tabellen- und Spaltennamen verwenden
  • Primärschlüssel in jeder Tabelle (vorzugsweise auto-increment)
  • Fremdschlüssel für referenzielle Integrität
  • Constraints nutzen (NOT NULL, UNIQUE, CHECK)
  • Dokumentation des Schemas pflegen

Performance-Optimierung

  • Indizes auf häufig abgefragte Spalten
  • EXPLAIN für Query-Analyse verwenden
  • SELECT * vermeiden – nur benötigte Spalten
  • WHERE-Klauseln so selektiv wie möglich
  • Joins minimieren, Subqueries bevorzugen
  • Connection Pooling für Web-Anwendungen

Sicherheit

  • Prepared Statements gegen SQL-Injection
  • Prinzip der geringsten Rechte (Least Privilege)
  • Separate Datenbank-User für verschiedene Anwendungen
  • Verschlüsselung (TLS für Verbindungen, TDE für Daten)
  • Regelmäßige Security-Audits
  • Sensible Daten (Passwörter, Kreditkarten) hashen

Backup & Recovery

  • Regelmäßige Backups (täglich, wöchentlich)
  • 3-2-1-Regel: 3 Kopien, 2 Medien, 1 extern
  • Recovery-Prozesse regelmäßig testen
  • Point-in-Time Recovery konfigurieren
  • Binary Logs für inkrementelle Backups
  • Backup-Verschlüsselung

FAQ – Häufige Fragen & Antworten

Häufige Fragen zu SQL-Datenbanken

Was ist der Unterschied zwischen SQL und NoSQL?

Die Hauptunterschiede zwischen SQL- und NoSQL-Datenbanken:

  • Struktur: SQL = tabellarisch (Tabellen mit Zeilen/Spalten), NoSQL = flexibel (Dokumente, Key-Value, Graph, Column-Family)
  • Schema: SQL = starres Schema (vorher definiert), NoSQL = dynamisches Schema (flexibel)
  • Skalierung: SQL = vertikal (leistungsstärkere Server), NoSQL = horizontal (mehr Server)
  • ACID: SQL = ACID-konform, NoSQL = oft BASE (Basically Available, Soft state, Eventual consistency)
  • Beispiele SQL: MySQL, PostgreSQL, Oracle
  • Beispiele NoSQL: MongoDB, Cassandra, Redis

Wann welches? SQL für strukturierte Daten mit klaren Beziehungen und Transaktionssicherheit. NoSQL für unstrukturierte Daten, hohe Skalierbarkeit und flexible Schemata.

Warum ist Normalisierung wichtig?

Normalisierung ist wichtig, weil sie:

  • Redundanzen reduziert: Dieselben Daten werden nicht mehrfach gespeichert (weniger Speicherplatz, weniger Inkonsistenzen)
  • Anomalien vermeidet: Update-Anomalien (Daten an mehreren Stellen ändern), Insert-Anomalien (Daten können nicht eingefügt werden), Delete-Anomalien (ungewolltes Löschen)
  • Datenintegrität verbessert: Konsistente Daten über die gesamte Datenbank
  • Wartbarkeit erhöht: Änderungen an einer Stelle statt an mehreren

Nachteil: Zu starke Normalisierung kann Performance-Probleme verursachen (viele Joins). In der Praxis: Zuerst normalisieren (3NF), dann bei Performance-Problemen gezielt denormalisieren.

Was ist SQL-Injection und wie verhindere ich sie?

SQL-Injection ist eine der häufigsten Sicherheitslücken in Webanwendungen. Ein Angreifer fügt schädlichen SQL-Code in Eingabefelder ein, um die Datenbank zu manipulieren.

Beispiel: Ein Login-Formular mit SELECT * FROM users WHERE username = '$user' AND password = '$pass'. Ein Angreifer gibt als Benutzername ' OR '1'='1 ein und erhält Zugriff ohne Passwort.

Prävention:

  • Prepared Statements: SQL-Code und Daten werden getrennt (z.B. SELECT * FROM users WHERE username = ?)
  • ORM-Frameworks: Hibernate, Entity Framework, Sequelize verwenden automatisch Prepared Statements
  • Input-Validierung: Alle Benutzereingaben validieren und sanitizen
  • Least Privilege: Datenbank-User mit minimalen Rechten
  • Web Application Firewall (WAF): Zusätzliche Schutzschicht
Wann sollte ich Indizes verwenden und wann nicht?

Indizes verwenden für:

  • Spalten, die oft in WHERE-Klauseln verwendet werden
  • Fremdschlüssel-Spalten (Join-Performance)
  • Spalten, die oft sortiert werden (ORDER BY)
  • Primärschlüssel (automatisch indiziert)
  • Spalten mit hoher Kardinalität (viele verschiedene Werte)

Keine Indizes für:

  • Sehr kleine Tabellen (Full Table Scan ist schneller)
  • Spalten mit niedriger Kardinalität (z.B. Geschlecht mit nur 2 Werten)
  • Tabellen mit vielen Schreiboperationen (jeder Index verlangsamt INSERT/UPDATE/DELETE)
  • Spalten, die selten abgefragt werden

Tipp: Verwenden Sie EXPLAIN SELECT... um zu sehen, ob Indizes verwendet werden und ob neue Indizes benötigt werden.

Was ist der Unterschied zwischen INNER JOIN und LEFT JOIN?

Der Hauptunterschied liegt in den zurückgegebenen Zeilen:

  • INNER JOIN: Gibt nur Zeilen zurück, die in beiden Tabellen übereinstimmen. Wenn eine Bestellung keinen Kunden hat, wird sie nicht angezeigt.
  • LEFT JOIN: Gibt alle Zeilen der linken Tabelle zurück, auch wenn keine Übereinstimmung in der rechten Tabelle existiert. Fehlende Werte werden als NULL angezeigt.

Beispiel: Tabelle users (100 Benutzer) und Tabelle orders (nur 80 Benutzer haben Bestellungen):

  • INNER JOIN: 80 Zeilen (nur Benutzer mit Bestellungen)
  • LEFT JOIN: 100 Zeilen (alle Benutzer, 20 mit NULL bei Bestellungen)

Wann welches? INNER JOIN, wenn Sie nur übereinstimmende Daten benötigen. LEFT JOIN, wenn Sie alle Daten der linken Tabelle benötigen, auch wenn keine Übereinstimmung existiert.

Wie skaliere ich eine SQL-Datenbank?

Es gibt zwei Hauptansätze zur Skalierung:

1. Vertikale Skalierung (Scale-Up):

  • Leistungsstärkerer Server (mehr CPU, RAM, SSD)
  • Einfach umzusetzen, aber begrenzt
  • Teuer bei sehr hohen Anforderungen
  • Single Point of Failure

2. Horizontale Skalierung (Scale-Out):

  • Replikation: Master-Slave-Setup (Schreiben auf Master, Lesen auf Slaves)
  • Sharding: Daten werden auf mehrere Server aufgeteilt (z.B. nach User-ID)
  • Clustering: Mehrere Server arbeiten als ein System (z.B. MySQL Cluster, Oracle RAC)

Empfehlung: Zuerst vertikal skalieren (einfacher), dann bei Bedarf horizontal skalieren. Replikation für Lese-Performance, Sharding für Schreib-Performance.

Was ist eine Transaktion und warum ist sie wichtig?

Eine Transaktion ist eine logische Einheit von Datenbankoperationen, die entweder vollständig oder gar nicht ausgeführt wird. Sie folgt dem ACID-Prinzip.

Beispiel: Banküberweisung von Konto A nach Konto B:

BEGIN TRANSACTION;
UPDATE kontos SET saldo = saldo - 100 WHERE konto_id = 'A';
UPDATE kontos SET saldo = saldo + 100 WHERE konto_id = 'B';
COMMIT;

Warum wichtig?

  • Atomicity: Wenn die zweite Operation fehlschlägt, wird die erste rückgängig gemacht
  • Consistency: Die Summe aller Kontostände bleibt gleich
  • Isolation: Parallele Transaktionen beeinflussen sich nicht
  • Durability: Nach COMMIT ist die Überweisung permanent

Ohne Transaktionen: Bei einem Systemausfall zwischen den beiden UPDATE-Statements wäre das Geld von A abgebucht, aber nicht bei B gutgeschrieben – das Geld wäre "verschwunden".

Welche SQL-Datenbank sollte ich für mein Projekt wählen?

Die Wahl hängt von Ihren Anforderungen ab:

  • MySQL/MariaDB: Webanwendungen, CMS (WordPress, Drupal), E-Commerce, kleine bis mittlere Unternehmen. Gute Performance, große Community, einfach zu erlernen.
  • PostgreSQL: Komplexe Anwendungen, Data Warehousing, GIS-Anwendungen, wissenschaftliche Projekte. Fortschrittlichste Features, beste Datenintegrität.
  • SQL Server: Windows-Ökosystem, .NET-Anwendungen, Business Intelligence (Power BI, SSRS), Enterprise-Umgebungen.
  • Oracle: Großunternehmen, Banken, geschäftskritische Systeme, höchste Skalierbarkeit und Verfügbarkeit. Teuer, aber leistungsstark.
  • SQLite: Mobile Apps, Embedded Systems, kleine Projekte, Testing, Prototyping. Keine Server-Konfiguration nötig.

Empfehlung für Einsteiger: Starten Sie mit PostgreSQL oder MySQL. Beide sind Open Source, haben große Communities und sind für die meisten Projekte ausreichend.

Zusammenfassung

Die wichtigsten Punkte

  • SQL-Datenbanken: Relationale Datenbanken mit strukturierten Tabellen und SQL-Abfragesprache
  • RDBMS-Systeme: MySQL, PostgreSQL, SQL Server, Oracle, SQLite, MariaDB
  • SQL-Kategorien: DDL (Struktur), DML (Daten), DQL (Abfragen), DCL (Rechte), TCL (Transaktionen)
  • ACID-Prinzipien: Atomicity, Consistency, Isolation, Durability – garantieren zuverlässige Transaktionen
  • Normalisierung: 1NF, 2NF, 3NF, BCNF – reduzieren Redundanzen und Anomalien
  • Joins: INNER, LEFT, RIGHT, FULL, CROSS, SELF – verbinden Tabellen
  • Indizes: Beschleunigen Abfragen, verlangsamen Schreiboperationen
  • Best Practices: Design, Performance, Sicherheit, Backup

Nächste Schritte

SQL-Datenbanken sind das Fundament der meisten Enterprise-Anwendungen. Nach dem Verständnis der Grundlagen sollten Sie:

  • Eine Datenbank installieren (PostgreSQL oder MySQL empfohlen)
  • SQL-Befehle praktisch üben (CREATE, INSERT, SELECT, UPDATE, DELETE)
  • Komplexe Joins und Subqueries ausprobieren
  • Indizes erstellen und Performance messen (EXPLAIN)
  • Transaktionen und ACID-Prinzipien testen
  • Backup und Recovery konfigurieren
Zu SQL-Befehlen

Weiterführende Themen

Datenbank-Grundlagen

Einführung in Datenbanken: Modelle, Architekturen und Grundlagen.

Zu Datenbank-Grundlagen
NoSQL-Datenbanken

MongoDB, Cassandra, Redis – alternative Datenbank-Modelle.

Zu NoSQL-Datenbanken
SQL-Befehle

Alle wichtigen SQL-Befehle mit Beispielen und Syntax.

Zu SQL-Befehlen
Datenbank-Optimierung

Performance-Optimierung: Indizes, Query-Tuning, Caching.

Zur Optimierung