Seite 2 - SQL

RANK und DENSE_RANK beantworten die Frage nach der absoluten Position einer Zeile in einer sortierten Menge, aber in vielen Auswertungen ist gar nicht die Position an sich interessant, sondern die relative Einordnung im Verhältnis zur Gesamtmenge. Liegt ein Wert im oberen Zehntel, in der Mitte oder eher am unteren Rand der Verteilung. Genau dafür existieren PERCENT_RANK und CUME_DIST, zwei Window Functions, die eine stufenlose Prozentangabe statt einer festen Rangzahl liefern. Dieser Artikel erklärt die zugrunde liegenden Formeln, den praktischen Unterschied zwischen beiden Funktionen, die Abgrenzung zu NTILE und typische Randfälle bei kleinen oder stark verzerrten Datensätzen.

FROM orders o, customers c WHERE o.customer_id = c.id sieht auf den ersten Blick wie eine harmlose Abkürzung für einen Join aus, und syntaktisch ist es auch nichts anderes. Die implizite Komma-Syntax stammt aus einer Zeit vor dem heute üblichen JOIN-Schlüsselwort und funktioniert in den meisten Datenbanksystemen bis heute unverändert. Der entscheidende Unterschied zur expliziten JOIN-Syntax liegt nicht im Ergebnis einer korrekt geschriebenen Abfrage, sondern in dem, was passiert, wenn ein Entwickler einen Fehler macht: Bei der Komma-Syntax verwandelt sich eine vergessene WHERE-Bedingung ohne jede Fehlermeldung in ein kartesisches Produkt. Dieser Artikel erklärt, warum das strukturell riskanter ist, wo die Komma-Syntax noch auftaucht, und warum explizites JOIN bei komplexen Abfragen auch die Lesbarkeit deutlich verbessert.

Datenbanksperren schützen üblicherweise konkrete Datenzeilen oder Tabellen vor gleichzeitigem, inkonsistentem Zugriff. Advisory Locks verfolgen einen anderen Zweck: Sie nutzen dieselbe robuste Locking-Infrastruktur der Datenbank, um beliebige Anwendungslogik zu koordinieren, ohne dass diese Sperre an eine konkrete Zeile oder Tabelle gebunden ist. Ein typischer Einsatzfall ist verteiltes Locking für Cron-Jobs oder Hintergrundprozesse, die auf mehreren Servern laufen könnten, aber niemals gleichzeitig denselben Vorgang ausführen dürfen.

Ein Endpunkt lädt eine Liste mit hundert Einträgen und feuert dabei hundert zusätzliche Einzelabfragen ab, eine pro Zeile. Das N+1 Problem entsteht selten aus schlechtem SQL, sondern aus der Art, wie Anwendungscode Beziehungen zwischen Tabellen nachlädt. Wer die Symptome im Query-Log erkennt, kann die Ursache gezielt mit JOINs oder Batch-Loading beheben, statt an Symptomen zu optimieren.

Ein EXPLAIN-Plan zeigt, wie eine Datenbank eine Abfrage tatsaechlich ausfuehrt, welche Indizes sie nutzt, in welcher Reihenfolge sie Tabellen verbindet und wie teuer jeder Schritt geschaetzt wird. Wer diesen Ausfuehrungsplan lesen kann, findet Performance-Probleme in Minuten statt durch Raten, und zwar unabhaengig davon, ob die Abfrage gegen MySQL, PostgreSQL oder SQL Server laeuft.

Das CAP Theorem wird oft als abstrakte Formel zitiert, ist aber vor allem eine praktische Entscheidungshilfe fuer den Moment, in dem ein Netzwerk tatsaechlich ausfaellt. Waehrend einer Partition muss ein verteiltes System entscheiden, ob es weiterhin konsistente Antworten gibt und dafuer Verfuegbarkeit opfert, oder ob es verfuegbar bleibt und dafuer voruebergehend inkonsistente Daten in Kauf nimmt.

NTILE(n) teilt eine sortierte Ergebnismenge in n moeglichst gleich grosse Buckets auf und macht Quartils-, Dezil- und allgemeine Perzentil-Analysen zu einer einzigen SQL-Abfrage. Statt Kundenwerte, Antwortzeiten oder Testergebnisse in eine Statistiksoftware zu exportieren, entstehen Verteilungs-Buckets direkt in der Datenbank, reproduzierbar und ohne manuelle Sortierarbeit.

Sobald eine Aggregation nach Joins über mehrere 1:n-Beziehungen gleichzeitig läuft, vervielfachen sich Zeilen, bevor SUM oder COUNT überhaupt zu rechnen beginnen, und die Ergebnisse werden unbemerkt zu hoch. Dieser Artikel erklärt das Fan-Out-Problem an einem konkreten Beispiel und zeigt, wie Vor-Aggregation in Subqueries und Window Functions falsche Summen zuverlässig verhindern.

Ein LATERAL Join erlaubt einer Subquery in FROM oder JOIN, auf Spalten der vorherigen Tabelle im selben Statement zuzugreifen, was ein gewoehnlicher Join oder eine gewoehnliche Subquery nicht kann. Damit werden Top-N-pro-Gruppe-Abfragen, dynamische Berechnungen pro Zeile und mehrspaltige Tabellenfunktionsaufrufe moeglich, in PostgreSQL mit LATERAL, in SQL Server mit CROSS APPLY und OUTER APPLY.

Ein Deadlock-Log-Eintrag wirkt beim ersten Lesen wie kryptischer Rauschtext, enthaelt aber alle Informationen, um die Ursache exakt zu rekonstruieren. Wer Deadlocks aus Logs systematisch analysiert, statt sie als seltenen Zufall abzutun, findet die zugrunde liegende Sperr-Reihenfolge im Code und behebt sie dauerhaft statt nur den naechsten Reconnect abzuwarten.