Dr. Hasan Dalmaz

› SELECT inst_id, instance_name, status FROM gv$instance ORDER BY inst_id;

▸ UNTERSCHIED

Mit RAC betreiben mehrere Server gemeinsam dieselbe Datenbank; fällt einer aus, bleibt das System verfügbar.

✓ STÄRKE

Die ausgereifteste Enterprise-Wahl für unterbrechungsfreien Betrieb und Disaster Recovery (Data Guard).

⚠ SCHWÄCHE

Hohe Lizenzkosten und erfordert Fachwissen; für kleine Projekte überdimensioniert.

→ IDEAL FÜR

Große Unternehmenssysteme, die keine Ausfallzeit vertragen: Banken, ERP.

› CREATE EXTENSION vector;

▸ UNTERSCHIED

Open Source; der Funktionsumfang lässt sich mit Extensions erweitern — etwa um Kartendaten oder Vektorsuche für KI.

✓ STÄRKE

Kostenlos, leistungsstark und standardkonform; bewältigt alles von einfachen Datensätzen bis zu komplexen Abfragen.

⚠ SCHWÄCHE

Systeme mit vielen Updates/Deletes benötigen regelmäßige VACUUM-Wartung und -Tuning.

→ IDEAL FÜR

Backends für Web- und Mobile-Apps, Kartografie (GIS) und KI-Projekte.

› CREATE AVAILABILITY GROUP ag_prod;

▸ UNTERSCHIED

Die Datenbank von Microsoft; arbeitet nahtlos mit der Windows-/.NET-Welt zusammen und bringt starke Werkzeuge mit (SSMS).

✓ STÄRKE

Bewältigt sowohl das Tagesgeschäft als auch Reporting/Analysen gut in einem System.

⚠ SCHWÄCHE

Läuft am besten unter Windows; die Lizenz der Enterprise Edition ist teuer.

→ IDEAL FÜR

Enterprise-.NET-Anwendungen und Business-Intelligence-/Reporting-Systeme.

› START REPLICA;

▸ UNTERSCHIED

Die beliebteste Datenbank im Web; einfach einzurichten und zu nutzen, mit einer riesigen Community.

✓ STÄRKE

Schlank und schnell; skaliert leicht, besonders bei leseintensiven Websites.

⚠ SCHWÄCHE

Bei sehr komplexen Analysen und anspruchsvollen Abfragen nicht so leistungsfähig wie Oracle/PostgreSQL.

→ IDEAL FÜR

Websites wie WordPress und leseintensive Web-Apps mit hohem Traffic.

› db.orders.find({ status: "paid" })

▸ UNTERSCHIED

Speichert Daten als flexible „Dokumente“ (JSON-ähnlich) statt in Tabellen; kein starres Schema erforderlich.

✓ STÄRKE

Ermöglicht schnelle Entwicklung, eignet sich gut für große, häufig wechselnde Datenmengen und skaliert leicht horizontal (Sharding).

⚠ SCHWÄCHE

Schlechtes Design kann zu Duplikaten und Inkonsistenzen führen; nicht die erste Wahl, wenn strikte relationale Integrität gefordert ist.

→ IDEAL FÜR

Kataloge, Content-Management und Anwendungen mit häufig wechselnden Strukturen.

› SET session:42 online EX 3600

▸ UNTERSCHIED

Hält Daten im Arbeitsspeicher (RAM) statt auf der Festplatte und antwortet daher nahezu sofort.

✓ STÄRKE

Extrem schnell; ideal für Caching, Sessions und Echtzeitzähler.

⚠ SCHWÄCHE

Die Daten müssen in den RAM passen und die Persistenz muss korrekt eingerichtet sein, sonst können Daten verloren gehen.

→ IDEAL FÜR

Caching, Session-Speicher, Bestenlisten und überall dort, wo Geschwindigkeit zählt.

› GET /products/_search?q=laptop

▸ UNTERSCHIED

Eine für die Textsuche entwickelte Engine; ihr invertierter Index durchsucht Millionen von Dokumenten und sortiert die Ergebnisse nach Relevanz.

✓ STÄRKE

Sehr schnelle Suche, Autovervollständigung und Log-/Analytics (ELK Stack); skaliert leicht horizontal.

⚠ SCHWÄCHE

Keine primäre Datenbank; läuft meist neben der Hauptdatenbank als Such-/Log-Schicht.

→ IDEAL FÜR

Website- und Produktsuche, Log-Analyse und Observability.

› SELECT * FROM orders JOIN users USING (id);

▸ UNTERSCHIED

Hält Daten geordnet in verknüpften Tabellen und fragt sie mit SQL ab; ein seit Jahrzehnten bewährtes Modell.

✓ STÄRKE

Starke Konsistenz: Eine Transaktion wird ganz oder gar nicht ausgeführt (ACID). Sehr leistungsfähig bei komplexen Abfragen.

⚠ SCHWÄCHE

Schwer auf viele Maschinen zu verteilen (Sharding); spätere Schemaänderungen erfordern sorgfältige Planung.

→ IDEAL FÜR

Geld, Lagerbestände und alle Systeme, bei denen Korrektheit entscheidend ist.

› { "user": "hd", "roles": ["dba"] }

▸ UNTERSCHIED

Nutzt flexible Strukturen statt starrer Tabellen (Dokument, Key-Value…); für große Skalierung ausgelegt.

✓ STÄRKE

Lässt sich leicht auf viele Maschinen verteilen und bewältigt hohe Schreiblasten problemlos.

⚠ SCHWÄCHE

Bietet meist weder die starken Konsistenzgarantien von SQL noch Tabellenverknüpfungen (JOIN).

→ IDEAL FÜR

Web im großen Maßstab, Echtzeitanalysen und flexibel strukturierte Daten.

› BEGIN; UPDATE acct SET bal = bal - 100; COMMIT;

▸ UNTERSCHIED

Zwei Konsistenzansätze: ACID garantiert, dass jede Transaktion vollständig abgeschlossen wird; BASE lockert dies zugunsten von Geschwindigkeit und Verfügbarkeit.

✓ STÄRKE

ACID bietet Verlässlichkeit für kritische Daten wie Geldbeträge; BASE ermöglicht enorme Skalierung und ständige Verfügbarkeit.

⚠ SCHWÄCHE

Bei BASE können Daten kurzzeitig „veraltet“ sein; die Anwendung muss das berücksichtigen.

→ IDEAL FÜR

ACID: Zahlungssysteme. BASE: Social-Media-Feeds, Like-Zähler.

› -- OLTP: point writes · OLAP: aggregate scans

▸ UNTERSCHIED

Zwei Arten von Workloads: OLTP umfasst viele kleine Transaktionen im Tagesgeschäft (Bestellungen, Zahlungen); OLAP die Analyse großer Datenmengen.

✓ STÄRKE

Die richtige Trennung beschleunigt beides: Ein System übernimmt das Tagesgeschäft, das andere das Reporting.

⚠ SCHWÄCHE

Beides auf einem System auszuführen bremst beide aus, daher werden sie meist getrennt.

→ IDEAL FÜR

OLTP: Bestellungen/Zahlungen. OLAP: Berichte, Dashboards und Data Warehouses.