Seite 7 - SQL

Stored Procedures polarisieren wie kaum ein anderes Thema in der Datenbankwelt: weniger Netzwerk-Roundtrips und feingranulare Zugriffskontrolle auf der einen Seite, schwer testbarer Code ohne einfache Versionierung auf der anderen Seite. Eine sachliche Abwaegung zeigt, in welchen Situationen Stored Procedures tatsaechlich das richtige Werkzeug sind und wo Anwendungscode die bessere Wahl bleibt.

Change Data Capture erfasst jede Aenderung an Datenzeilen nahezu in Echtzeit, statt sie in periodischen Abfragen zu suchen. Log-basiertes CDC liest direkt aus dem Transaktionslog der Datenbank und liefert Aenderungen zuverlaessig an nachgelagerte Systeme, ohne die Quelldatenbank mit zusaetzlicher Last zu belasten.

OFFSET-basierte Pagination wird mit jeder weiteren Seite langsamer, weil die Datenbank alle uebersprungenen Zeilen trotzdem lesen und verwerfen muss. Keyset-Pagination, auch Cursor-Pagination genannt, ersetzt den Seitenzaehler durch einen Vergleich mit dem letzten gesehenen Wert und liefert dadurch konstante Antwortzeiten, unabhaengig davon, wie tief man in die Ergebnismenge blaettert.

Ohne belastbares Auditing von Datenbankzugriffen bleibt nach einem Sicherheitsvorfall nur Raten: welche Zeilen wurden gelesen, wer hat einen Wert geaendert, seit wann laeuft ein verdaechtiger Zugriff schon. Trigger-basierte Protokollierung, pgAudit und Immutable Storage machen aus dieser Ungewissheit eine nachvollziehbare, gerichtsfeste Spur, die auch Compliance-Anforderungen wie DSGVO oder PCI-DSS erfuellt.

LAST_VALUE liefert ohne angepasste Frame-Klausel fast nie den tatsaechlich letzten Wert einer Partition, weil der Standard-Fensterrahmen an der aktuellen Zeile endet. FIRST_VALUE und LAST_VALUE praktisch richtig einzusetzen bedeutet, den Fensterrahmen explizit auf die gesamte Partition auszudehnen, statt sich auf einen unsichtbaren Standardwert zu verlassen.

ROW_NUMBER, RANK und DENSE_RANK sehen auf den ersten Blick fast identisch aus und verhalten sich doch grundlegend verschieden, sobald zwei Zeilen denselben Wert teilen. Wer den Unterschied nicht kennt, baut fehlerhafte Deduplizierungen und falsche Ranglisten. Dieser Artikel zeigt das exakte Verhalten aller drei Rangfunktionen an konkreten Beispielen mit Gleichstand.

Datenintegritaet, die nur bei Bedarf manuell nachgeprueft wird, ist bereits verletzt, bevor jemand hinschaut. Automatisierte Pruefungen aus Constraints, Checksummen und statistischen Anomalie-Checks decken Inkonsistenzen auf, lange bevor sie zu falschen Berichten oder fehlerhaften Geschaeftsentscheidungen fuehren.

Eine gute Index-Strategie haengt nicht davon ab, welches ORM oder Framework auf der Datenbank aufsetzt, sondern von grundlegenden Prinzipien wie Selektivitaet, Spaltenreihenfolge und dem gezielten Einsatz von Covering Indexes. Wer diese Prinzipien einmal verstanden hat, trifft bessere Indexentscheidungen, unabhaengig davon, ob die Anwendung in PHP, Java, Python oder direkt in SQL geschrieben ist.

UNION und UNION ALL kombinieren beide Ergebnismengen mehrerer SELECT-Anweisungen zu einer einzigen Ausgabe, aber nur UNION dedupliziert dabei jede einzelne Zeile mit einem impliziten Sortier- oder Hashschritt. Wer diesen Unterschied nicht kennt, bezahlt bei jeder Abfrage unnoetig Rechenzeit fuer eine Deduplizierung, die in vielen Faellen gar nicht noetig ist, weil die kombinierten Ergebnismengen ohnehin disjunkt sind.

Wenn DQL an seine Grenzen stößt, weil eine native SQL-Funktion wie JSON_EXTRACT oder MATCH AGAINST fehlt, ist eine eigene DQL-Funktion oft die sauberere Lösung als der komplette Ausweich auf native Queries. Die FunctionNode-API von Doctrine macht genau das möglich.