Warum der Dialekt-Selektor wichtig ist
SQL ist ein Standard in etwa so, wie Englische Rechtschreibung ein Standard ist. Jede Engine implementiert den gemeinsamen Kern und fügt dann Syntax hinzu, die sonst keiner hat, und ein Formatter, der nicht weiß, welche Engine du anvisierst, wird diese Syntax entweder falsch parsen oder stillschweigend unformatiert durchreichen.
Die Unterschiede sind nicht exotisch. Allein die Identifier-Quoting teilt das Feld: MySQL verwendet Backticks, PostgreSQL und Standard-SQL verwenden doppelte Anführungszeichen, und SQL Server verwendet eckige Klammern. Ein Formatter, der die falsche Konvention annimmt, kann einen gequoteten Identifier als Zeichenketten-Literal behandeln und die Abfrage um eine Grenze herum neu umbrechen, die gar nicht existiert. Neben dem Quoting gibt es LIMIT versus TOP versus FETCH FIRST, PostgresQLs ::-Cast-Operator, T-SQL-Variablen mit @-Präfix, BigQuerys Backtick-gewrapperte Projektpfade und Snowflakes QUALIFY-Klausel. Den richtigen Dialekt zu wählen, ist das, was diese intakt hält.
Einrückung ist eine Diff-Entscheidung
Die Einrückungsbreite und Schlüsselwort-Großschreibung wirken kosmetisch, aber sie bestimmen, wie deine Versionskontroll-Historie aussieht. Formatierung ist nur nützlich, wenn sie konsistent ist, denn sobald zwei Personen dieselbe Datei unterschiedlich formatieren, trägt jeder Commit eine Welle unzusammenhängender Whitespace-Änderungen mit sich, und Code-Review hört auf zu funktionieren. Wähle eine Konfiguration, schreibe sie in das Repository und wende sie mechanisch an.
Großgeschriebene Schlüsselwörter sind die häufigste Konvention, und sie helfen beim Lesen einer dichten Abfrage, weil sich die Strukturwörter visuell von deinen Tabellen- und Spaltennamen abheben. Kleinschreibung hat in Codebasen an Boden gewonnen, die SQL als gewöhnlichen Code behandeln und das Schreien nicht mögen. Beibehalten ist die richtige Wahl, wenn du die Abfrage von jemand anderem formatierst und das Layout ändern willst, ohne ein einziges Zeichen seines Texts anzufassen, was den resultierenden Diff rein strukturell macht.
Tabs versus Leerzeichen hat das übliche Argument anhängen, mit einer SQL-spezifischen Falte: Abfragen werden häufig in Terminals, Ticket-Systeme und Chat-Clients eingefügt, die einen Tab als acht Spalten rendern. Eine tief verschachtelte Abfrage, die mit Tabs eingerückt ist, kann genau an den Stellen unlesbar umbrechen, an denen du sie am ehesten teilst.
Was ein Formatter nicht tun wird
Formatierung ist rein präsentativ. Sie macht eine Abfrage nicht schneller, und sie ändert nichts am Plan, den der Optimierer erzeugt. Eine wunderschön eingerückte korrelierte Unterabfrage läuft weiterhin einmal pro Zeile. Verwende EXPLAIN für Performance-Arbeit; verwende einen Formatter für Lesbarkeit.
Sie validiert auch nicht. Dieses Werkzeug parst gerade gut genug, um den Text neu zu fließen, aber es ist nicht der Parser der Engine und es wird eine Abfrage mit falsch geschriebenem Spaltennamen oder fehlender Join-Bedingung fröhlich formatieren. Ein sauberes Format ist keine Syntaxprüfung, und die einzige Autorität darüber, ob eine Abfrage gültig ist, ist die Datenbank, auf der du sie ausführen willst.
Die eine Gewohnheit, die man neben dem Formatieren übernehmen sollte, ist Parameterisierung. Eine Abfrage zu formatieren, in deren String Werte eingefügt wurden, macht das Injektionsrisiko lesbarer, aber nicht weniger real. Wenn du feststellst, dass du SQL formatierst, das Nutzereingaben direkt in den Text eingespleißt enthält, ist das Formatieren nicht das Problem, das zuerst behoben werden sollte.