Seite 3 - SQL

Normalisierung ist der systematische Prozess, eine Tabelle so in kleinere, verknuepfte Tabellen aufzuteilen, dass jede Information genau einmal gespeichert wird. Dieser Beitrag zeigt anhand einer einzigen, durchgehenden Bestelltabelle Schritt fuer Schritt, was die erste, zweite und dritte Normalform jeweils fordern, welche konkrete Anomalie sie beseitigen und wie das Ergebnis als echte SQL-Tabellenstruktur aussieht.

Wer Auswertungen bisher nur mit GROUP BY gelost hat, verliert dabei immer die Einzelzeilen. Window Functions losen genau dieses Problem: Sie berechnen Summen, Rangfolgen und Durchschnitte uber definierte Fenster von Zeilen, ohne das Ergebnis auf eine Zeile pro Gruppe zu reduzieren. Dieser Artikel erklart die OVER-Klausel, PARTITION BY und ORDER BY Schritt fur Schritt anhand von echten Beispielen.

PARTITION BY ist der Baustein in der OVER-Klausel, der aus einer globalen Berechnung eine gruppierte macht, ohne dass dabei Zeilen verschwinden. Dieser Artikel zeigt anhand echter Reporting-Beispiele, wie Ein-Spalten- und Mehr-Spalten-Partitionierung funktionieren, wie PARTITION BY mit ORDER BY zusammenspielt und wo typische Fehler bei der Anwendung lauern.

Schema-Änderungen in Produktionsdatenbanken sind riskant — aber mit der richtigen Vorbereitung, den richtigen Werkzeugen und einem klaren Rollback-Plan sind sie beherrschbar.

sales_order richtig lesen, Nettoumsatz korrekt berechnen, Rückerstattungen berücksichtigen und die drei häufigsten Denkfehler bei Magento Revenue-Reports vermeiden – mit vollständiger SQL-Abfrage.

Wo sich die beiden Datenbanksysteme wirklich trennen: JSON-Binärformat, SEQUENCE Engine, system-versioned Tables, GTID-Implementierungen, Galera vs. InnoDB Cluster und was das für Magento bedeutet.

NULL SQL ist nicht dasselbe wie leer, false oder 0 — und genau darin liegt die Quelle von Bugs, leeren Ergebnismengen und stillen Fehlern in Produktionsdatenbanken.

Ein Trigger kann Datenintegrität und Audit-Trails garantieren, unabhängig davon, welche Anwendung gerade schreibt. Er kann aber auch unsichtbare, schwer wartbare Business-Logik erzeugen, wenn er falsch eingesetzt wird. Dieser Beitrag zeigt BEFORE gegen AFTER, Row-Level gegen Statement-Level, echte Audit-Trail-Muster, Rekursionsfallen und klare Kriterien, wann ein Trigger sparsam und gezielt eingesetzt werden sollte.

Ein Datenbankschema veraendert sich ueber Jahre durch viele kleine Migrationen, und ohne systematische Regressionstests bleibt unklar, ob eine neue Aenderung stillschweigend eine bestehende Anwendung bricht. Schema-Snapshots, Contract-Tests und automatisierte Diff-Checks machen genau das sichtbar, bevor ein Deployment Schaden anrichtet.

LAG und LEAD losen ein Problem, das fruher fast immer einen Self-Join erforderte: den Zugriff auf den Wert der vorherigen oder nachsten Zeile innerhalb einer sortierten Reihenfolge. Ob Month-over-Month-Vergleiche, Trendanalysen oder die Erkennung von Lucken in einer Zeitreihe, dieser Artikel zeigt die Syntax, die Offset- und Default-Parameter und die praktischen Anwendungsfalle von LAG und LEAD im Detail.