bg_image
header

Datenbanktrigger

Datenbank-Trigger (kurz: Trigger) sind spezielle automatische Aktionen in einer Datenbank, die ausgelöst werden, wenn bestimmte Ereignisse auf einer Tabelle oder Sicht (View) passieren.


🔧 Was macht ein Trigger?

Ein Trigger ist ein vordefinierter Code, der bei INSERT, UPDATE oder DELETE auf einer Tabelle automatisch ausgeführt wird – ohne dass der Benutzer ihn direkt aufruft.


🧠 Beispiel:

Stell dir vor, du hast eine Tabelle Bestellungen, und du willst, dass immer, wenn eine Bestellung gelöscht wird, diese Info in einer Tabelle Log gespeichert wird.

Dann schreibst du einen DELETE-Trigger für die Tabelle Bestellungen, der automatisch beim Löschen etwas in Log schreibt.


🔄 Arten von Triggern:

Typ Beschreibung
BEFORE Wird vor der Aktion ausgeführt
AFTER Wird nach der Aktion ausgeführt
INSTEAD OF (bei Views) ersetzt die Aktion komplett
CREATE TRIGGER log_delete
AFTER DELETE ON Bestellungen
FOR EACH ROW
BEGIN
  INSERT INTO Log (aktion, zeitpunkt)
  VALUES ('Bestellung gelöscht', NOW());
END;

✅ Wofür werden Trigger verwendet?

  • Validierung von Daten

  • Automatisches Logging

  • Business-Logik abbilden

  • Referentielle Integrität erweitern


⚠️ Nachteile:

  • Schwer zu debuggen

  • Können unbemerkt viele Aktionen auslösen

  • Beeinflussen Performance, wenn komplex


PHP Data Objects - PDO

PDO steht für PHP Data Objects und ist eine Datenbank-Abstraktionsschicht in PHP. Es handelt sich um eine objektorientierte Schnittstelle, mit der du auf verschiedene Datenbanken zugreifen kannst – z. B. MySQL, PostgreSQL, SQLiteohne den Datenbankspezifischen Code stark ändern zu müssen.

Hauptmerkmale von PDO:

Einheitliche API:
Egal ob MySQL, SQLite oder PostgreSQL – du benutzt denselben Code-Stil.

Prepared Statements:
Sicherer Schutz vor SQL-Injektionen durch gebundene Parameter:

$stmt = $pdo->prepare("SELECT * FROM users WHERE id = :id");
$stmt->execute(['id' => $userId]);

Transaktionen:
PDO unterstützt Transaktionen (wichtig z. B. bei Bankbuchungen).

Fehlerbehandlung per Exception:

$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);

Flexibler Datenbankwechsel:
Möchtest du von MySQL auf PostgreSQL wechseln? Meist nur der DSN-String und Treiber müssen geändert werden.

$dsn = 'mysql:host=localhost;dbname=testdb;charset=utf8mb4';
$user = 'root';
$pass = '';

try {
    $pdo = new PDO($dsn, $user, $pass);
    $pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
    echo "Verbindung erfolgreich!";
} catch (PDOException $e) {
    echo "Verbindung fehlgeschlagen: " . $e->getMessage();
}

Fazit:

PDO ist der empfohlene Weg, um in modernen PHP-Anwendungen mit Datenbanken zu arbeiten – besonders wegen der Sicherheit und Flexibilität.


Data Query Language - DQL

DQL steht für Data Query Language und ist ein Teil der SQL-Sprache (Structured Query Language). Sie dient dazu, Daten aus einer Datenbank abzufragen, ohne sie zu verändern.

Hauptmerkmal von DQL:

  • Nur lesend: Mit DQL werden Daten abgefragt, aber nicht eingefügt, verändert oder gelöscht.

  • Der zentral verwendete Befehl ist:

SELECT

Beispiel:

SELECT name, geburtsdatum FROM kunden WHERE stadt = 'Berlin';

Dieser Befehl liest die Namen und Geburtsdaten aller Kunden aus, die in Berlin wohnen – verändert aber nichts an den Daten.


DQL im Vergleich zu anderen SQL-Teilen:

Teil Bedeutung Hauptfunktion
DQL Data Query Language Daten lesen
DML Data Manipulation Language Daten einfügen, ändern, löschen (INSERT, UPDATE, DELETE)
DDL Data Definition Language Tabellen und Strukturen definieren (CREATE, ALTER, DROP)
DCL Data Control Language Rechte vergeben (GRANT, REVOKE)
TCL Transaction Control Language Transaktionen steuern (COMMIT, ROLLBACK)

MariaDB

MariaDB ist ein relationales Datenbankmanagementsystem (RDBMS), das als Open-Source-Alternative zu MySQL entwickelt wurde. Es wurde 2009 von den ursprünglichen Entwicklern von MySQL ins Leben gerufen, nachdem MySQL von Oracle übernommen wurde. Ziel war es, eine vollständig offene und kompatible Version von MySQL bereitzustellen, die unabhängig bleibt.

Hauptmerkmale von MariaDB:

  1. Open Source:

    • MariaDB steht unter der GPL (General Public License), was garantiert, dass es kostenlos genutzt, modifiziert und verbreitet werden kann.
  2. Kompatibilität mit MySQL:

    • MariaDB ist weitgehend kompatibel mit MySQL. Viele Anwendungen, die MySQL nutzen, können direkt auf MariaDB umgestellt werden, ohne großen Anpassungsaufwand.
    • Die gleiche Befehlssyntax, APIs und Konfigurationsdateien werden verwendet.
  3. Erweiterte Funktionen:

    • Neue Speicher-Engines: MariaDB bietet zusätzliche Speicher-Engines wie Aria, TokuDB und ColumnStore.
    • Bessere Performance: Optimierungen für Abfragen und Indexierungen sorgen für eine höhere Geschwindigkeit und Skalierbarkeit.
    • Verschlüsselung: Verbesserte Sicherheitsfeatures, wie Verschlüsselung auf Tabellen- und Spaltenebene.
    • JSON- und Virtuelle Spalten: Unterstützt moderne Datentypen für flexible Anwendungen.
  4. Aktive Weiterentwicklung:

    • MariaDB wird von der Community und der MariaDB Foundation aktiv weiterentwickelt, wodurch regelmäßig neue Funktionen und Verbesserungen eingeführt werden.

Typische Einsatzgebiete:

  • Webanwendungen: Zum Beispiel Content-Management-Systeme (CMS) wie WordPress.
  • Unternehmenslösungen: Für ERP-, CRM- oder Data-Warehouse-Anwendungen.
  • Cloud-Dienste: Viele Cloud-Provider unterstützen MariaDB.

Unterschied zu MySQL:

  • Während MySQL unter Oracles Leitung teilweise proprietäre Erweiterungen bietet, bleibt MariaDB vollständig Open Source.
  • MariaDB bietet zusätzliche Funktionen und ist für Nutzer interessant, die vollständige Kontrolle über ihre Datenbank behalten möchten.

Fazit:

MariaDB ist eine leistungsstarke und flexible Datenbanklösung, die vor allem wegen ihrer Offenheit, Sicherheit und Kompatibilität mit MySQL in der Entwickler-Community sehr geschätzt wird.

 


Objektorientiertes Datenbanksystem - OODBMS

Ein objektorientiertes Datenbanksystem (OODBMS) ist ein Datenbanksystem, das die Prinzipien der objektorientierten Programmierung (OOP) mit den Funktionalitäten einer Datenbank kombiniert. Es ermöglicht das Speichern, Abrufen und Verwalten von Daten in Form von Objekten, wie sie in objektorientierten Programmiersprachen (z. B. Java, Python oder C++) definiert werden.

Merkmale eines OODBMS:

  1. Objektmodell:

    • Die Daten werden als Objekte gespeichert, ähnlich wie in einer objektorientierten Programmiersprache.
    • Jedes Objekt hat Attribute (Daten) und Methoden (Funktionen, die mit diesen Daten arbeiten).
  2. Klassen und Vererbung:

    • Objekte werden auf Basis von Klassen definiert.
    • Vererbung ermöglicht es, von bestehenden Klassen neue abzuleiten, wodurch Code- und Datenwiederverwendung gefördert wird.
  3. Kapselung:

    • Die Daten und die zugehörigen Operationen (Methoden) sind im Objekt gebündelt.
    • Dies verbessert die Datenintegrität und reduziert die Wahrscheinlichkeit von Inkonsistenzen.
  4. Persistenz:

    • Objekte, die normalerweise nur im Arbeitsspeicher existieren, werden im OODBMS dauerhaft gespeichert, sodass sie auch nach dem Beenden des Programms erhalten bleiben.
  5. Identität:

    • Jedes Objekt hat eine eindeutige Identität (OID – Objektidentifikator), unabhängig von seinen Attributwerten. Dies unterscheidet es von relationalen Datenbanken, bei denen die Identität oft durch den Primärschlüssel definiert wird.
  6. Komplexe Datentypen:

    • OODBMS unterstützt komplexe Datentypen, wie z. B. verschachtelte Objekte oder Arrays, ohne dass sie in einfache Tabellenform umgewandelt werden müssen.

Vorteile eines OODBMS:

  • Nahtlose Integration mit OOP: Entwickler können dieselbe Struktur wie in ihrer Programmiersprache verwenden, ohne Daten in relationale Tabellen zu konvertieren.
  • Komplexe Datenstrukturen: Es ist ideal für Anwendungen mit komplexen Daten, z. B. CAD-Systeme, Multimedia-Anwendungen oder wissenschaftliche Daten.
  • Bessere Performance: Weniger Konvertierung zwischen Programm- und Datenbankebene.

Nachteile eines OODBMS:

  • Geringe Verbreitung: Im Vergleich zu relationalen Datenbanksystemen (RDBMS) wie MySQL oder PostgreSQL sind OODBMS weniger verbreitet.
  • Standardisierung: Es gibt weniger standardisierte Abfragesprachen (wie SQL in RDBMS).
  • Steilere Lernkurve: Entwickler müssen sich mit den Prinzipien der Objektorientierung und der spezifischen Implementierung des OODBMS auseinandersetzen.

Beispiele für OODBMS:

  • ObjectDB (für Java-Entwickler optimiert)
  • Versant Object Database
  • db4o (open-source, für Java und .NET)
  • GemStone/S

Objektorientierte Datenbanken sind besonders nützlich, wenn es darum geht, mit komplexen, hierarchischen oder verschachtelten Datenstrukturen zu arbeiten, wie sie in vielen modernen Softwareprojekten vorkommen.

 


Object Query Language - OQL

Object Query Language (OQL) ist eine Abfragesprache, die ähnlich wie SQL (Structured Query Language) funktioniert, aber speziell für objektorientierte Datenbanken entwickelt wurde. Sie wird verwendet, um Daten aus objektorientierten Datenbanksystemen (OODBs) abzufragen, die Daten als Objekte speichern. OQL wurde als Teil des Object Data Management Group (ODMG)-Standards definiert.

Merkmale von OQL:

  1. Objektorientierte Ausrichtung:

    • Im Gegensatz zu SQL, das sich auf relationale Datenmodelle konzentriert, arbeitet OQL mit Objekten und deren Beziehungen.
    • OQL kann Objekteigenschaften und Methoden direkt ansprechen.
  2. Ähnlichkeit mit SQL:

    • Viele OQL-Syntaxelemente basieren auf SQL, was den Einstieg für Entwickler erleichtert, die bereits SQL kennen.
    • Es gibt jedoch zusätzliche Funktionen zur Unterstützung von objektorientierten Konzepten wie Vererbung, Polymorphismus und Methodenaufrufen.
  3. Abfragen von komplexen Objekten:

    • Mit OQL kann man komplexe Datenstrukturen wie verschachtelte Objekte, Sammlungen (z. B. Listen, Sets) und Assoziationen abfragen.
  4. Unterstützung für Methoden:

    • OQL ermöglicht den Aufruf von Methoden auf Objekten, was SQL nicht bietet.
  5. Kompatibilität mit objektorientierten Programmiersprachen:

Beispiel für eine OQL-Abfrage:

Angenommen, es gibt eine Datenbank mit einer Klasse Person mit den Attributen Name und Age. Eine OQL-Abfrage könnte wie folgt aussehen:

SELECT p.Name
FROM Person p
WHERE p.Age > 30

Diese Abfrage gibt die Namen aller Personen zurück, deren Alter größer als 30 ist.

Einsatzgebiete von OQL:

  • OQL wird häufig in Anwendungen verwendet, die mit objektorientierten Datenbanken arbeiten, z. B. CAD-Systeme, wissenschaftliche Datenbanken oder komplexe Geschäftsanwendungen.
  • Es eignet sich besonders gut für Systeme, die mit vielen Beziehungen und Hierarchien zwischen Objekten arbeiten.

Vorteile von OQL:

  • Direkte Unterstützung von Objektstrukturen und Methoden.
  • Effiziente Abfrage komplexer Daten.
  • Gute Integration mit objektorientierten Programmiersprachen.

Herausforderungen:

  • Weniger weit verbreitet als SQL, da relationale Datenbanken dominieren.
  • Komplexer bei der Nutzung und Implementierung in Vergleich zu SQL.

In der Praxis ist OQL weniger populär als SQL, da relationale Datenbanken nach wie vor weit verbreitet sind. Allerdings ist OQL in spezialisierten Anwendungen, die objektorientierte Datenmodelle nutzen, sehr leistungsfähig.

 

 


Data Definition Language - DDL

Die Data Definition Language (DDL) ist ein Bestandteil von SQL (Structured Query Language) und umfasst Befehle, die zur Definition und Verwaltung der Struktur einer Datenbank verwendet werden. DDL-Befehle ändern die Metadaten einer Datenbank, also Informationen über Tabellen, Indizes, Schemata und andere Datenbankobjekte, anstatt die eigentlichen Daten zu manipulieren.

Wichtige DDL-Befehle:

1. CREATE
Wird verwendet, um neue Datenbankobjekte wie Tabellen, Schemata, Views oder Indizes zu erstellen.
Beispiel:

CREATE TABLE Kunden (
    ID INT PRIMARY KEY,
    Name VARCHAR(50),
    Alter INT
);

2. ALTER
Dient zur Änderung der Struktur von existierenden Objekten, z. B. Hinzufügen oder Entfernen von Spalten.
Beispiel:

ALTER TABLE Kunden ADD Email VARCHAR(100);

3. DROP
Entfernt ein Datenbankobjekt (z. B. eine Tabelle) dauerhaft.
Beispiel:

DROP TABLE Kunden;

4. TRUNCATE
Löscht alle Daten aus einer Tabelle, behält jedoch die Struktur der Tabelle bei. Es ist schneller als ein DELETE, da keine Transaktionsprotokolle erstellt werden.
Beispiel:

TRUNCATE TABLE Kunden;

Eigenschaften von DDL-Befehlen:

  • Änderungen durch DDL-Befehle sind automatisch permanent (implizites Commit).
  • Sie beeinflussen die Datenbankstruktur, nicht die Daten selbst.

DDL ist essenziell für das Design und die Verwaltung einer Datenbank und wird meist zu Beginn eines Projekts oder bei strukturellen Änderungen verwendet.

 

 


Character Large Object - CLOB

Ein Character Large Object (CLOB) ist ein Datentyp, der in Datenbanksystemen verwendet wird, um große Mengen an Textdaten zu speichern. Es ist eine Abkürzung für "Character Large Object". CLOBs eignen sich besonders für die Speicherung von Texten wie Dokumenten, HTML-Inhalten oder anderen großen Zeichenfolgen, die mehr Speicherplatz benötigen, als Standard-Textfelder bieten können.

Eigenschaften eines CLOB:

  1. Größe:
    • Ein CLOB kann sehr große Datenmengen speichern, oft bis zu mehrere Gigabytes, abhängig vom Datenbankmanagementsystem (DBMS).
  2. Speicherung:
    • Die Daten werden in der Regel außerhalb der eigentlichen Tabelle gespeichert, mit einem Verweis in der Tabelle auf die Speicherposition des CLOB.
  3. Verwendung:
    • CLOBs werden häufig in Anwendungen eingesetzt, die große Textdaten wie Artikel, Berichte oder Bücher speichern und verwalten müssen.
  4. Unterstützte Operationen:
    • Viele DBMS bieten Funktionen für den Umgang mit CLOBs, etwa das Lesen, Schreiben, Suchen und Bearbeiten von Text innerhalb eines CLOB.

Beispiele von Datenbanken, die CLOB unterstützen:

  • Oracle Database: Bietet CLOB für umfangreiche Textdaten.
  • MySQL: Verwendet TEXT-Typen, die ähnlich wie CLOBs arbeiten.
  • PostgreSQL: Unterstützt CLOB-ähnliche Typen über TEXT oder spezielle Datentypen.

Vorteile:

  • Ermöglicht die Speicherung und Verarbeitung von Texten, die weit über die Begrenzungen von Standard-Datentypen hinausgehen.

Nachteile:

  • Kann die Performance beeinträchtigen, da Operationen auf CLOBs oft langsamer sind als auf regulären Datenfeldern.
  • Erfordert mehr Speicherplatz und ist datenbankabhängig in der Implementierung.

 


ACID

ACID ist ein Akronym, das vier zentrale Eigenschaften beschreibt, die für die Zuverlässigkeit von Datenbanktransaktionen in einem Datenbankmanagementsystem (DBMS) entscheidend sind. Diese Eigenschaften gewährleisten die Integrität der Daten und die Konsistenz der Datenbank auch bei Fehlern oder Systemabstürzen. ACID steht für:

  1. Atomicity (Atomarität):

    • Jede Transaktion wird als eine unteilbare Einheit betrachtet. Das bedeutet, entweder wird die gesamte Transaktion vollständig ausgeführt, oder gar nicht. Wenn ein Teil der Transaktion fehlschlägt, wird die gesamte Transaktion rückgängig gemacht und die Datenbank bleibt in einem konsistenten Zustand.
  2. Consistency (Konsistenz):

    • Jede Transaktion führt die Datenbank von einem konsistenten Zustand in einen anderen konsistenten Zustand. Das bedeutet, dass nach Abschluss einer Transaktion alle Integritätsbedingungen der Datenbank erfüllt sind. Konsistenz stellt sicher, dass keine Transaktion die Datenbank in einen ungültigen Zustand versetzt.
  3. Isolation (Isolation):

    • Transaktionen werden isoliert voneinander ausgeführt. Das bedeutet, dass die Ausführung einer Transaktion so erfolgen muss, als ob sie die einzige Transaktion in der Datenbank ist. Die Ergebnisse einer laufenden Transaktion sind für andere Transaktionen nicht sichtbar, bis die Transaktion abgeschlossen ist. Dies verhindert, dass parallele Transaktionen einander beeinflussen und zu Inkonsistenzen führen.
  4. Durability (Dauerhaftigkeit):

    • Nach Abschluss einer Transaktion (d.h., wenn sie „committed“ ist) bleiben die Änderungen dauerhaft erhalten, selbst im Falle eines Systemabsturzes oder eines anderen Fehlers. Die Dauerhaftigkeit wird in der Regel durch das Schreiben der Änderungen auf nicht-flüchtige Speicher wie Festplatten sichergestellt.

Beispiel zur Verdeutlichung

Stellen wir uns vor, wir haben eine Bankdatenbank mit zwei Konten: Konto A und Konto B. Eine Transaktion überweist einen Betrag von 100 Euro von Konto A auf Konto B. Die ACID-Eigenschaften gewährleisten Folgendes:

  • Atomicity: Wenn die Überweisung aus irgendeinem Grund fehlschlägt (z.B. wegen eines Systemabsturzes), wird die gesamte Transaktion rückgängig gemacht. Konto A wird nicht belastet und Konto B erhält keinen Betrag.
  • Consistency: Die Transaktion stellt sicher, dass die Gesamtmenge des Geldes in beiden Konten vor und nach der Transaktion gleich bleibt (wenn keine anderen Faktoren ins Spiel kommen). Falls Konto A ursprünglich 200 Euro und Konto B 300 Euro hatte, sollte das Gesamtsaldo von 500 Euro nach der Transaktion unverändert bleiben.
  • Isolation: Wenn zwei Überweisungen gleichzeitig stattfinden, beeinflussen sie sich nicht gegenseitig. Jede Transaktion sieht die Datenbank so, als wäre sie die einzige laufende Transaktion.
  • Durability: Sobald die Transaktion abgeschlossen ist, sind die Änderungen dauerhaft. Selbst wenn nach der Transaktion ein Stromausfall auftritt, bleibt der neue Kontostand von Konto A und Konto B erhalten.

Bedeutung von ACID

Die ACID-Eigenschaften sind entscheidend für die Zuverlässigkeit und Integrität von Datenbanktransaktionen, insbesondere in Systemen, die mit sensiblen Daten arbeiten, wie Finanzinstitutionen, E-Commerce-Plattformen und kritischen Geschäftsanwendungen. Sie helfen, Datenverlust und -beschädigung zu verhindern und stellen sicher, dass Daten konsistent und vertrauenswürdig bleiben.

 


Least Recently Used - LRU

Least Recently Used (LRU) ist ein Konzept aus der Informatik, das häufig bei Speicher- und Cache-Management-Strategien angewendet wird. Es beschreibt eine Methode zur Verwaltung des Speicherplatzes, bei der die am wenigsten kürzlich verwendeten Daten zuerst entfernt werden, um Platz für neue Daten zu schaffen. Hier sind einige Hauptanwendungen und Details von LRU:

  1. Cache-Management: In einem Cache wird der Speicherplatz oft knapp. LRU ist eine Strategie, um zu entscheiden, welche Daten aus dem Cache entfernt werden sollen, wenn neuer Speicherplatz benötigt wird. Das grundlegende Prinzip lautet: Wenn der Cache voll ist und ein neuer Eintrag hinzugefügt werden muss, wird der Eintrag entfernt, der am längsten nicht mehr verwendet wurde. Diese Methode stellt sicher, dass häufig verwendete Daten im Cache bleiben und schnell zugänglich sind.

  2. Speicherverwaltung in Betriebssystemen: Betriebssysteme verwenden LRU, um zu entscheiden, welche Seiten aus dem physischen Speicher (RAM) auf die Festplatte ausgelagert werden sollen, wenn neuer Speicher benötigt wird. Die Seite, die am längsten nicht verwendet wurde, wird als am wenigsten nützlich angenommen und daher zuerst ausgelagert.

  3. Datenbanken: Datenbank-Management-Systeme (DBMS) verwenden LRU, um den Zugriff auf oft abgefragte Daten zu optimieren. Tabellen oder Indexseiten, die am längsten nicht abgefragt wurden, werden zuerst aus dem Speicher entfernt, um Platz für neue Abfragen zu schaffen.

Implementierung

LRU kann auf verschiedene Arten implementiert werden, abhängig von den Anforderungen und der Komplexität. Zwei gängige Implementierungen sind:

  • Verkettete Liste: Eine doppelt verkettete Liste kann verwendet werden, bei der jeder Zugriff auf eine Seite die Seite an den Anfang der Liste verschiebt. Die Seite am Ende der Liste wird entfernt, wenn neuer Speicherplatz benötigt wird.

  • Hash-Map und Doppelt Verkettete Liste: Diese Kombination bietet eine effizientere Implementierung mit einer durchschnittlichen Zeitkomplexität von O(1) für Zugriff, Einfügen und Löschen. Die Hash-Map speichert die Adressen der Elemente, und die doppelt verkettete Liste verwaltet die Reihenfolge der Elemente.

Vorteile

  • Effizienz: LRU ist effizient, weil es sicherstellt, dass häufig verwendete Daten schnell zugänglich bleiben.
  • Einfachheit: Die Idee hinter LRU ist einfach zu verstehen und zu implementieren, was es zu einer beliebten Wahl macht.

Nachteile

  • Overhead: Die Verwaltung der Datenstrukturen kann zusätzlichen Speicher- und Rechenaufwand erfordern.
  • Nicht immer optimal: In einigen Szenarien, z.B. bei zyklischen Zugriffsmustern, kann LRU weniger effektiv sein als andere Strategien wie Least Frequently Used (LFU) oder adaptive Algorithmen.

Insgesamt ist LRU eine bewährte und weit verbreitete Strategie zur Speicherverwaltung, die hilft, die Leistung von Systemen zu optimieren, indem sie sicherstellt, dass die am häufigsten verwendeten Daten schnell zugänglich bleiben.