SQL

Wer SQL nur zum Datenabrufen einsetzt, löst dieselben Probleme immer wieder im Application-Code. Anti-Join, Window Functions, CTEs und Conditional Aggregation ersetzen PHP-Schleifen durch Datenbankoperationen, die dafür gebaut sind – und machen Queries gleichzeitig kürzer, schneller und leichter testbar.

SQL wird in einer anderen Reihenfolge ausgeführt als es geschrieben wird. Wer das nicht weiß, schreibt Queries die zufällig funktionieren — oder zufällig nicht. Diese SQL Grundlagen räumen mit den häufigsten Denkfehlern auf.

Graph-Abfragen fuer Hierarchien, Organisationsstrukturen und Netzwerke lassen sich mit Adjazenzlisten, rekursiven CTEs und Closure Tables direkt in einer relationalen Datenbank abbilden, ohne fuer jeden vernetzten Anwendungsfall gleich eine dedizierte Graphdatenbank einzufuehren. Wer die Grenzen dieses Ansatzes kennt, trifft die richtige Wahl fuer die eigene Datenmenge und Abfragetiefe.

Ein SQL-Review, das nur auf Einrueckung und Variablennamen schaut, uebersieht die Fehler, die spaeter in Produktion richtig teuer werden. Eine systematische Checkliste aus Lesbarkeit, Korrektheit, Performance-Red-Flags und Sicherheitspruefungen macht SQL-Code-Reviews reproduzierbar statt vom Bauchgefuehl des Reviewers abhaengig.

Ein Soft Delete markiert eine Zeile als geloescht, ohne sie physisch zu entfernen, klingt nach einer einzigen zusaetzlichen Spalte und entpuppt sich in der Praxis als Quelle fuer Unique-Constraint-Konflikte, aufgeblaehte Indizes und vergessene WHERE-Bedingungen. Dieser Beitrag zeigt drei etablierte Modelle fuer Soft Deletes und ordnet ein, wann welches wirklich passt.

Optimistic Locking loest gleichzeitige Schreibzugriffe ohne Datenbank-Sperren, indem jede Zeile eine Versionsspalte traegt und ein UPDATE nur dann erfolgreich ist, wenn die Version beim Schreiben noch mit der beim Lesen gesehenen Version uebereinstimmt. Weicht die Anzahl betroffener Zeilen von eins ab, hat eine andere Transaktion zwischenzeitlich geschrieben, und die Anwendung muss den Konflikt gezielt behandeln.

Die Wahl des Primaerschluessels ist eine der folgenreichsten Entscheidungen beim Tabellenentwurf: ein fachlicher Natural Key wie eine E-Mail-Adresse oder eine Produkt-SKU traegt Bedeutung, ein kuenstlicher Surrogate Key wie ein Auto-Increment-Wert oder eine UUID ist stabil und bedeutungslos. Dieser Beitrag vergleicht beide Strategien konkret, zeigt zusammengesetzte Schluessel als dritte Option und liefert einen praktischen Entscheidungsleitfaden.

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.