\u00dcberblick<\/h2>\n
SQL und Software-Programmiersprachen folgen unterschiedlichen Paradigmen. Software wird als Folge von Einzelanweisungen erstellt. SQL hingegen ist darauf ausgelegt, viele Arbeitsschritte in einer einzigen Anweisung auszuf\u00fchren. Ein einziges SQL-Statement erstreckt sich im Gegensatz zu einer Software-Anweisung manchmal \u00fcber hunderte Zeilen.<\/p>\n
Integrierte Entwicklungsumgebungen wie Microsoft Visual Studio unterst\u00fctzen bei der Software-Entwicklung sehr gut mit automatischer Quellcode-Formatierung. Anders sieht es bei der Entwicklung von SQL-Artefakten im SQL Server Management Studio (SSMS) aus. SSMS unterst\u00fctzt den Entwickler nur m\u00e4\u00dfig bis gar nicht.<\/p>\n
Hieraus ergibt sich eine besondere Herausforderung ein gutes SQL-Statement zu schreiben.<\/p>\n
SQL stellt einen reichen Wortschatz zur Verf\u00fcgung. Der Kern von SQL ist jedoch die Abfrage von Daten. Daf\u00fcr steht zumindest die Abk\u00fcrzung SQL: Structured Query Language. Als Synonym hierf\u00fcr kann das SELECT Statement angesehen werden. In diesem Artikel habe ich einige Best Practice Regeln f\u00fcr die Strukturierung und Formatierung eines SELECT-Statements zusammengetragen. Nat\u00fcrlich lassen sich die hier genannten Regeln ohne weiteres auch auf ein INSERT-, UPDATE- oder DELETE-Statement anwenden, genauso aber auch auf die Schl\u00fcsselworte f\u00fcr die Ablaufsteuerung von Statements: IF\u2026ELSE, TRY\u2026CATCH, WHILE, etc.<\/p>\n
S\u00e4mtliche Best Practices haben gemein, dass gleichartige Elemente nach M\u00f6glichkeit linksb\u00fcndig ausgerichtet und einheitlich einzur\u00fccken sind. Durch die Einr\u00fcckung wird ein Statement strukturiert. Durch eine einheitliche Ausrichtung gleichartiger Sprachelemente erh\u00e4lt das Statement einen tabellenartigen Aufbau. Beides dient einer schnellen visuellen Erfassung und Navigation auch innerhalb komplexer Statements. Nat\u00fcrlich ist es nicht m\u00f6glich, beiden Forderungen immer zu entsprechen.<\/p>\n
Wenn sich alle Entwickler eines Mehrentwicklerprojektes auf eine einheitliche Notation einigen k\u00f6nnen, wird jeder Entwickler und werden vor allem neue Team-Mitglieder dieses sehr schnell sch\u00e4tzen lernen. Folgende Aspekte der Strukturierung von SQL Statements werden hier betrachtet:<\/p>\n
- \n
- Einr\u00fcckung<\/li>\n
- Grundlegende Sprachelemente<\/li>\n
- SELECT Feldliste<\/li>\n
- WHERE Klausel<\/li>\n
- FROM Klausel<\/li>\n
- GROUP BY,\u00a0HAVING,\u00a0ORDER BY Klauseln<\/li>\n<\/ul>\n
Allgemeines zur Einr\u00fcckung<\/h2>\n
Unter dem Aspekt der Lesbarkeit und schnellen Erfassung der Kapitel ist diese einger\u00fcckte Version eines Inhaltsverzeichnisses im Vergleich zu der nachfolgenden nicht einger\u00fcckten Variante informativer und intuitiver:<\/p>\n
1. Kapitel der ersten Ebene\n 1.1. Kapitel der zweiten Ebene\n 1.1.1. Kapitel der dritten Ebene\n 1.1.2. Kapitel der dritten Ebene\n 1.2. Kapitel der zweiten Ebene\n 1.2.1. Kapitel der dritten Ebene\n 1.2.2. Kapitel der dritten Ebene\n 1.2.3. Kapitel der dritten Ebene\n 1.2.4. Kapitel der dritten Ebene\n 1.3. Kapitel der zweiten Ebene\n 1.3.1. Kapitel der dritten Ebene\n 1.3.2. Kapitel der dritten Ebene\n 1.3.3. Kapitel der dritten Ebene\n2. Kapitel der ersten Ebene\n 2.1. Kapitel der zweiten Ebene\n 2.1.1. Kapitel der dritten Ebene\n 2.1.2. Kapitel der dritten Ebene\n 2.2. Kapitel der zweiten Ebene\n 2.2.1. Kapitel der dritten Ebene\n 2.2.2. Kapitel der dritten Ebene<\/pre>\n
Zum Vergleich ein Inhaltsverzeichnis ohne Einr\u00fcckung<\/p>\n
1. Kapitel der ersten Ebene\n1.1. Kapitel der zweiten Ebene\n1.1.1. Kapitel der dritten Ebene\n1.1.2. Kapitel der dritten Ebene\n1.2. Kapitel der zweiten Ebene\n1.2.1. Kapitel der dritten Ebene\n1.2.2. Kapitel der dritten Ebene\n1.2.3. Kapitel der dritten Ebene\n1.2.4. Kapitel der dritten Ebene\n1.3. Kapitel der zweiten Ebene\n1.3.1. Kapitel der dritten Ebene\n1.3.2. Kapitel der dritten Ebene\n1.3.3. Kapitel der dritten Ebene\n2. Kapitel der ersten Ebene\n2.1. Kapitel der zweiten Ebene\n2.1.1. Kapitel der dritten Ebene\n2.1.2. Kapitel der dritten Ebene\n2.2. Kapitel der zweiten Ebene\n2.2.1. Kapitel der dritten Ebene\n2.2.2. Kapitel der dritten Ebene<\/pre>\n
Sicherlich lassen sich auch Inhaltsverzeichnisse finden, die unter graphischen Gesichtspunkten komplett linksb\u00fcndig ausgerichtet sind. Um die \u00dcbersichtlichkeit links ausgerichteter Inhaltsverzeichnisse zu erh\u00f6hen, werden dann allerdings auch Formatierungs-Optionen (Gro\u00df-\/Klein-Schreibung, Fett, Kursiv, \u2026) auf die Kapitel der gleichen Ebene angewendet.<\/p>\n
Formatierungsoptionen stehen in SSMS nicht zur Verf\u00fcgung. Daher bleibt als strukturierendes Mittel lediglich die Einr\u00fcckung.<\/p>\n
Grundlegende Sprachelemente<\/h2>\n
<\/a><\/p>\n
Ein SELECT-Statement besteht aus den folgenden grundlegenden Klauseln:<\/p>\n
SELECT<\/strong>
FROM<\/strong>
WHERE<\/strong>
GROUP BY<\/strong>
HAVING<\/strong>
ORDER BY<\/strong><\/p>\nBetrachtet man die genannten Hauptelemente als Elemente der ersten Ebene w\u00e4ren die jeweils zul\u00e4ssigen Sprachelemente der zweiten Ebene gem\u00e4\u00df der Forderung aus dem vorigen Kapitel einzur\u00fccken. Daraus ergibt sich die folgende grundlegende Struktur eines SQL Statements:<\/p>\n
SELECT\n\u00a0 \u00a0Feldliste \nFROM\n\u00a0 \u00a0Datenquellen\nWHERE\n\u00a0 \u00a0Bedingungen auf Datenquelle\nGROUP BY\n\u00a0 \u00a0Gruppierungsfelder\nHAVING\n\u00a0 \u00a0Bedingungen auf Aggregationen\nORDER BY\n\u00a0 \u00a0Sortier-Felder<\/pre>\n
In jedem Fall sollten die Hauptelemente eines SQL-Statements in separaten Zeilen notiert werden.<\/p>\n
Als Abgrenzung hierzu m\u00f6chte ich zwei Beispiele f\u00fcr Formatierungen geben, die h\u00e4ufig zu finden sind und die diese klare Strukturierung nicht ber\u00fccksichtigen. In beiden Beispielen ist der Leser des Statements dazu gezwungen das Statement zumindest in Teilen zu lesen, um zu erfassen, wo ein Hauptelement beginnt und wo er aufh\u00f6rt.<\/p>\n
Linksb\u00fcndige Ausrichtung von Haupt- und Unterelementen<\/h3>\n
Gelegentlich findet man dass Elemente der obersten Ebene und die jeweils zul\u00e4ssigen Elemente der n\u00e4chsten Ebene gleicherma\u00dfen einger\u00fcckt sind. Zu beobachten ist das insbesondere innerhalb der FROM Klausel. Die Datenquellen (Tabellen\/Views\/CTE’s) sind genauso einger\u00fcckt wie das einleitende Schl\u00fcsselwort FROM<\/strong>:<\/p>\n
SELECT\nFeldliste \nFROM\nTabelle1\nJOIN Tabelle2 ON [...]\nJOIN Tabelle2 ON [...]\nWHERE\nBedingungen auf Datenquelle\nGROUP BY\nGruppierungsfelder\nHAVING\nBedingungen auf Aggregationen\nORDER BY\nSortier-Felder<\/pre>\n
Rechtsb\u00fcndige Ausrichtung von Schl\u00fcsselw\u00f6rtern<\/h3>\n
In diesem Beispiel sind die grundlegenden Klauseln des SELECT<\/strong> Statements \u2013 ohne Ber\u00fccksichtigung des Schl\u00fcsselwortes BY<\/strong> \u2013 rechtsb\u00fcndig ausgerichtet. Durch diese Art der Einr\u00fcckung entsteht zus\u00e4tzlich ein erh\u00f6hter Aufwand f\u00fcr die Ausrichtung der Elemente, da man mit unterschiedlich starken Einr\u00fcckungen arbeiten muss.<\/p>\n
SELECT Feld1, Feld2, Feld3\n FROM Tabelle1\n LEFT JOIN Tabelle2 ON [...]\n LEFT JOIN Tabelle2 ON [...]\n WHERE Bedingung1\n OR Bedingung2\n OR Bedingung3\n GROUP BY Gruppierungsfelder\nHAVING Bedingung1\n OR Bedingung2\n OR Bedingung3\n ORDER BY Sortier-Felder\n WHERE Klausel<\/pre>\n
SELECT Feldliste<\/h2>\n
<\/a><\/p>\n
Die nat\u00fcrliche Leserichtung (eines SQL-Statements) ist von links nach rechts und von oben nach unten. Mit Blick auf die Navigationsm\u00f6glichkeiten mit Tastatur und der Maus erscheint die vertikale Navigation um einiges leichter als die horizontale Navigation. Das Mausrad und die Bild auf<\/strong>\/Bild ab<\/strong>\u00a0\u00a0\u00a0\u00a0 Tasten erm\u00f6glichen eine schnelle vertikale Navigation auch innerhalb langer komplexer Statements, wenn Feldlisten untereinandergeschrieben werden.<\/p>\n
Feldnamen sollten daher als vertikale Liste mit vorangestellten Kommas geschrieben werden (s. a. Formatierung von SQL-Statements (Teil 1)<\/strong>; Abschnitt Das Komma<\/strong>). Je Zeile ist nur ein Feld zu notieren. Da die Feldliste dem Schl\u00fcsselwort SELECT<\/strong> logisch untergeordnet ist, sind die Feldnamen entsprechend der vereinbarten Einr\u00fcckungsweite einzur\u00fccken.<\/p>\n
SELECT\n \u00a0 \u00a0Feldl1\n\u00a0 \u00a0,Feldl2\n\u00a0 \u00a0,Feldl3\nFROM [...]\u00a0 \u00a0\nWHERE\u00a0[...]\nGROUP BY\n \u00a0 \u00a0Feldl1 \u00a0 \u00a0\n ,Feldl2\n\u00a0 \u00a0,Feldl3 \nHAVING [...]\nORDER BY [...]\n \u00a0 \u00a0Feldl1 \u00a0 \u00a0\n ,Feldl2\n\u00a0 \u00a0,Feldl3<\/pre>\n
WHERE-Klausel<\/h2>\n
<\/a><\/p>\n
Die WHERE<\/strong>-Klausel sei an dieser Stelle entgegen der Abfolge der Hauptelemente eines SELECT<\/strong>-Statements als n\u00e4chstes erl\u00e4utert, da die hier aufgestellten Forderungen gleicherma\u00dfen auf die FROM<\/strong>– und die HAVING<\/strong>-Klauseln anwendbar sind. Eine WHERE<\/strong>-Klausel enth\u00e4lt einen oder mehrere Constraints, die durch logische Operatoren verkn\u00fcpft sind. Bei der Formatierung von Constraints in der WHERE Klausel sind zwei Punkte besonders zu ber\u00fccksichtigen.<\/p>\n
- \n
- Ausrichtung von Operanden<\/li>\n
- Einr\u00fcckung gleichwertiger Constraints<\/li>\n<\/ul>\n
Ausrichtung von Operanden<\/h3>\n
Ein einfacher Constraint besteht normalerweise aus zwei Operanden und einem Operator: (=<\/strong>, !=<\/strong>, <><\/strong>, IN, NOT IN<\/strong>, etc. In einem komplexen Constraint, der aus mehreren einzelnen Constraints zusammengesetzt ist, sind die Operanden und Operatoren jeweils linksb\u00fcndig untereinander auszurichten. In dem folgenden Beispiel sind die Feldnamen unterschiedlich lang und es werden unterschiedliche Operatoren angewendet:<\/p>\n
[...]\nWHERE\n \u00a0 \u00a0\u00a0\u00a0\u00a0T01.[Feld___1]\u00a0\u00a0\u00a0 =\u00a0 'Irgendwas'\n \u00a0 AND T01.[Feld__2]\u00a0\u00a0\u00a0\u00a0 <> 1\n \u00a0 AND T01.[Feld_____3]\u00a0 NOT IN (1, 2, 3)\n\u00a0\u00a0 AND T01.[Feld4]\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 = T02.[Feld5]<\/pre>\n
Hieraus ergibt sich eine tabellenartige Notation der Constraints, die dem Leser eine schnelle und sichere visuelle Navigation innerhalb der Bestandteile der Constraints erlaubt.<\/p>\n
Einr\u00fcckung gleichwertiger Constraints<\/h3>\n
Enth\u00e4lt die WHERE Klausel mehr als einen Constraints , sind diese mit einem logischen Operator, wie zum Beispiel dem UND<\/strong> oder ODER<\/strong> zu verkn\u00fcpfen. Bei komplexen Constraints kann auch die Verwendung von Klammern erforderlich sein, um die Auswertungsreihenfolge der einzelnen Ausdr\u00fccke festzulegen. Je nach Komplexit\u00e4t des Gesamtausdrucks sind die einzelnen Ausdr\u00fccke bisweilen stark verschachtelt.<\/p>\n
Um komplexe und verschachtelte Ausdr\u00fccke besser lesen zu k\u00f6nnen, sollte der Strukturierung und Formatierung einer WHERE Klausel besondere Aufmerksamkeit gewidmet werden: Gleichwertige Constraints sollten untereinander mit gleicher Einr\u00fcckung notiert werden. Eine logische Verkn\u00fcpfung von gleichwertigen Constraints wird mit einer Einr\u00fcckung notiert, die der Verarbeitungsreihenfolge der Constraints entspricht.<\/p>\n
[...]\nWHERE (\n (\n [Operand01] = [Operand02]\n OR [Operand03] = [Operand05]\n OR [Operand05] = [Operand06]\n )\n AND (\n \u00a0 \u00a0 [Operand07] = [Operand08]\n OR [Operand09] = [Operand10]\n )\n AND [Operand11] = [Operand12] \n )\nOR (\n [Operand13] = [Operand14]\n )<\/pre>\n
Die logischen Verkn\u00fcpfungen von Teilausdr\u00fccken k\u00f6nnen bei entsprechender Einr\u00fcckung in lesbarer Form pr\u00e4sentiert werden. Ein Screenshot der gleichen WHERE Klausel in Notepad++ mag die Begr\u00fcndung hierf\u00fcr einleuchtender erscheinen lassen, da die Klammern bzw. die jeweilige Einr\u00fcckung \u00fcber vertikale Hilfslinien im Abstand der Tabulatorweite nachvollziehbarer sind:<\/p>\n
![\"\"](\"https:\/\/sql.marcus-belz.de\/wp-content\/uploads\/2018\/06\/post00090001.png\")
<\/a><\/p>\nFROM Klausel<\/h2>\n
Folgen wir dem Dogma des strukturierten Aufbaus eines SQL-Statements, sind auch die untergeordneten Elemente der FROM<\/strong> Klausel einger\u00fcckt zu notieren. In der Regel handelt es sich hier um die Angabe von Datenquellen, also Tabellen, Views und Common Table Expressions.<\/p>\n
Anmerkung zu Sub-SELECTS<\/strong><\/p>\n
Sub-SELECT-Statements sollten in einer FROM Klausel vermieden werden. Sub-SELECTS machen ein SQL Statement unleserlich und k\u00f6nnen viel \u00fcbersichtlicher als Common Table Expressions (CTE) notiert und damit auch mehrfach innerhalb eines SQL Statements verwendet werden.<\/p>\n
Damit ist bei der Festlegung einer Formatierungsanweisung auf die Bestandteile der JOIN<\/strong>-Statements abzustellen:<\/p>\n
- \n
- Tabelle<\/li>\n
- JOIN Operator<\/li>\n
- ON Schl\u00fcsselwort<\/li>\n
- JOIN Constraints<\/li>\n<\/ul>\n
In dem folgenden Codebeispiel hat der Leser keinen visuellen Anker f\u00fcr die Identifikation der Elemente der FROM-Klausel:<\/p>\n
FROM<\/strong>\nTabelle1 T01\nJOIN Tabelle2 T02\nON T01.[FK] = T02.[ID]\nJOIN Tabelle3 T030 ON\nT02.[FK] = T03.[ID]\nJOIN Tabelle4 T04\nON\u00a0T03.[FK] = T04.[ID]\nWHERE<\/strong>\n[...]<\/pre>\n
Die m\u00f6glichen Elemente der FROM<\/strong> Klausel geh\u00f6ren nach meiner Auffassung der Lesbarkeit wegen in separate Zeilen. Als Ausnahme hiervon sollten herangejointe Tabellen direkt hinter dem JOIN Operator stehen. Das Schl\u00fcsselwort ON<\/strong> steht linksb\u00fcndig zu dem JOIN Operator<\/strong> in der folgenden Zeile. F\u00fcr die JOIN Constraints<\/strong> versuche ich die Festlegungen f\u00fcr die WHERE<\/strong>-Klausel anzuwenden.<\/p>\n
SELECT\n [...]\nFROM\n Tabelle1 T01\n JOIN Tabelle2 T02\n ON\n T01.[FK] = T02.[ID]\n JOIN Tabelle3 T030\n ON\n T02.[FK1] = T03.[Fk1]\n AND T02.[Feld2] = T03.[Feld2]\n JOIN Tabelle4 T04\n ON\n T03.[FK] = T04.[ID]\nWHERE\n [...]<\/pre>\n
GROUP BY,\u00a0HAVING,\u00a0ORDER BY<\/h2>\n