Seite 14 - SQL

Das EAV-Modell in Magento trennt Entitäten, Attribute und Werte auf mehrere Tabellen auf. Das macht es flexibel und gleichzeitig schwer lesbar. Dieser Artikel erklärt die Struktur vollständig und zeigt praxisnahe SQL-Muster.

Eine normale View ist nichts weiter als eine gespeicherte Abfrage, die bei jedem Zugriff neu ausgefuehrt wird und deshalb immer aktuelle Daten liefert, aber keinen Speicherplatz fuer die Ergebnisse belegt. Eine Materialized View speichert das Ergebnis physisch und liest bei Zugriffen nur noch diese gespeicherten Daten, wird dadurch schneller, aber potenziell veraltet, bis ein Refresh die Daten wieder synchronisiert.

Bedingte Aggregation gehört zu den häufigsten Anforderungen in Reporting-Queries: Wie viele Bestellungen sind storniert, wie viele abgeschlossen, wie viele noch offen, alles in einer einzigen Zeile pro Gruppe. Der klassische Weg dorthin führt über COUNT in Kombination mit einem CASE-WHEN-Ausdruck, der je nach Bedingung entweder einen Wert oder NULL zurückgibt. Der SQL-Standard bietet seit einiger Zeit eine deutlich klarere Alternative: die FILTER-Klausel, direkt an die Aggregatfunktion angehängt. Dieser Artikel zeigt, wie FILTER funktioniert, warum es CASE-WHEN in vielen Fällen an Lesbarkeit übertrifft, wie es sich mit Window Functions für mehrere parallele Kennzahlen kombinieren lässt und wo die Grenzen der Datenbank-Verfügbarkeit liegen.

Der Datentyp einer Spalte lässt sich in einer wachsenden Tabelle nur mit erheblichem Aufwand ändern, weshalb die erste Entscheidung besonders sorgfältig getroffen werden sollte. Dieser Beitrag behandelt INT gegen BIGINT bei Primärschlüsseln, realistische VARCHAR-Längen, DECIMAL statt FLOAT für Geldbeträge und die häufigsten Zeitzonen-Fallstricke bei Timestamps, mit konkretem SQL für jede Entscheidung.

Wer den Zustand einer Zeile zu einem beliebigen Zeitpunkt in der Vergangenheit rekonstruieren muss, baut klassischerweise eine eigene Audit-Trail-Tabelle mit Triggern oder Anwendungscode. Der SQL:2011-Standard definiert dafür eine robustere Alternative: system-versionierte Tabellen, bei denen die Datenbank selbst bei jedem UPDATE und DELETE automatisch eine vollständige Historie mit gültigen Zeiträumen pflegt, ganz ohne zusätzlichen Anwendungscode. SQL Server und MariaDB implementieren dieses Konzept bereits produktionsreif, mit eigener Syntax für Zeitreise-Abfragen. Dieser Artikel zeigt, wie die Technik konkret funktioniert, wo sie sich von handgebauten Audit-Trails unterscheidet und wo ihre Grenzen liegen.

Ein CHECK Constraint kann weit mehr als einen positiven Preis erzwingen. Mehrspalten-Bedingungen, Zustandsautomaten für Statusfelder, IMMUTABLE-Funktionen und EXCLUDE Constraints gegen überlappende Zeiträume machen aus einer simplen Wertebereichsprüfung ein Werkzeug für komplexe Geschäftsregeln, die sonst nur mit Triggern oder Anwendungscode abgebildet würden.

Ein Self-Join verknuepft eine Tabelle mit sich selbst und wirkt auf den ersten Blick wie eine akademische Uebung, ist in der Praxis aber das Werkzeug fuer drei sehr konkrete Probleme: hierarchische Beziehungen wie Mitarbeiter und Vorgesetzte abbilden, doppelte Datensaetze anhand fachlicher Kriterien aufspueren und aufeinanderfolgende Zeilen, etwa Ereignisse oder Preise, direkt miteinander vergleichen, ohne dafuer prozedurale Schleifen zu benoetigen.

Eine langsame Abfrage ist selten ein Zufall, sie hat fast immer eine von einer Handvoll wiederkehrender Ursachen. Diese Checkliste fuehrt Entwickler Schritt fuer Schritt durch die Query-Optimierung, von der WHERE-Klausel ueber fehlende Indizes bis zum N+1-Problem, damit die meisten Faelle geloest sind, bevor ueberhaupt eine DBA konsultiert werden muss.

ROWS und RANGE definieren beide einen Window Frame, tun das aber auf grundlegend verschiedene Weise: ROWS zaehlt physische Zeilenpositionen, RANGE betrachtet logische Wertebereiche der Sortierspalte. Bei eindeutigen Sortierwerten liefern beide dasselbe Ergebnis, bei Duplikaten in der Sortierspalte koennen ROWS und RANGE fuer dieselbe Abfrage unterschiedliche Zahlen produzieren.

Full Text Search ist einer der Bereiche, in denen der SQL Standard bewusst wenig vorschreibt und jede Datenbank eine eigene, proprietaere Loesung entwickelt hat. Dieser Artikel vergleicht die Volltextsuche-Implementierungen von PostgreSQL, MySQL und SQL Server, zeigt Indizierung und Relevanz-Ranking anhand konkreter Beispiele und ordnet ein, wo dedizierte Suchmaschinen wie Elasticsearch sinnvoller sind als Full Text Search direkt in der Datenbank.