SQL-Formatierer

Ein Formatierer, der Schlüsselwörter durch Abgleichen ganzer Wörter mit einem regulären Ausdruck großschreibt, hat keine Möglichkeit zu wissen, ob ein gegebenes Vorkommen von „order" das SQL-Schlüsselwort `ORDER` (wie in `ORDER BY`) oder ein Zeichenkettenliteralwert ist, der zufällig dieses Wort enthält — eine Abfrage, die Zeilen mit `WHERE description = 'the order from stock'` filtert, hat das Wort „order" innerhalb einer Zeichenkette in Anführungszeichen, wo es überhaupt nicht als Schlüsselwort fungiert. Ein naiver Formatierer schreibt jedes übereinstimmende Wort ohne Rücksicht auf den Kontext groß und verdirbt den Zeichenkettenliteralwert zu `'the ORDER FROM stock'`, wodurch still geändert wird, was die Abfrage tatsächlich filtert. Die Abfrage korrekt zu tokenisieren — die Grenzen von Zeichenketten in Anführungszeichen zu erkennen, bevor entschieden wird, was als Schlüsselwort zählt — verhindert das, und es ist genau die Art von Fehler, der nur bei echten Daten mit Wörtern auftaucht, die zufällig SQL-Schlüsselwörtern entsprechen, daher leicht beim Testen mit einfachen Beispielabfragen zu übersehen.

Dieses Tool erkennt die gemeinsame Klauselstruktur zwischen PostgreSQL, MySQL, SQL Server, SQLite und Oracle — SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY und ihre Verwandten — gut genug, um jede Klausel auf ihrer eigenen Zeile einzurücken und Unterabfragen korrekt zu verschachteln. Es baut kein vollständiges Verständnis der gesamten Grammatik einer bestimmten Datenbank auf, einschließlich anbieterspezifischer Erweiterungen wie PostgreSQLs Array-Syntax oder SQL Servers Platzierung der `TOP`-Klausel. Die praktische Konsequenz ist, dass dialektspezifische Syntax unangetastet durch den Formatierer läuft, statt einen Fehler zu verursachen, aber sie erhält auch nicht dieselbe sorgfältige Einrückung wie die gemeinsamen Klauseln — ein vernünftiger Tausch, um fünf Dialekte mit einem einzigen Formatierer zu unterstützen, statt ein separates Tool pro Datenbank-Engine zu benötigen.

SQL-Schlüsselwörter unterscheiden nach der Sprachspezifikation selbst nicht zwischen Groß- und Kleinschreibung — `SELECT`, `Select` und `select` sind für jede SQL-Engine identisch — was genau das ist, was ihre Groß- oder Kleinschreibung zu einer rein kosmetischen Operation ohne jedes Risiko macht, das Verhalten zu ändern. Dasselbe gilt für Leerzeichen und Zeilenumbrüche, die dieser Formatierer hinzufügt: Eine über zwölf eingerückte Zeilen verteilte Abfrage läuft identisch zu derselben in einer Zeile zusammengedrängten Abfrage. Nichts an der Formatierung berührt die echten Tokens, die bestimmen, welche Tabellen gelesen werden, welche Bedingungen Zeilen filtern, oder welche Werte eingefügt werden — nur wie dieselbe logische Abfrage visuell für einen Menschen angeordnet wird, der sie danach liest.

Eine von einem ORM generierte, aus einer grafischen Datenbankoberfläche exportierte, oder während einer eiligen Migration als eine einzige lange Zeile geschriebene Abfrage ist oft funktional korrekt, aber für eine Person wirklich schwer zu überprüfen, wie sie geschrieben ist — eine Abfrage mit fünfzehn Joins ohne Zeilenumbrüche erschwert zu sehen, welche Bedingungen zu welchem Join gehören, oder ob eine WHERE-Klausel die richtige Tabelle filtert. Sie mit jeder Klausel und jedem Join auf seiner eigenen Zeile neu zu formatieren, eingerückt, um die echte Struktur der Abfrage widerzuspiegeln, ist oft der schnellste Weg, wirklich zu verstehen, was eine lange generierte Abfrage tut, bevor sie in einem Code-Review genehmigt wird oder debuggt wird, warum sie die falschen Zeilen zurückgibt.