SQL-Formatierer und -Optimierer

Der SQL-Formatierer und -Optimierer ist ein kostenloses Tool, das SQL-Code übersichtlicher und einheitlich formatiert ausgibt.

Was ändert die SQL-Formatierung?

Die SQL-Formatierung verändert die Darstellung einer Abfrage, damit sich Klauseln, Ausdrücke und verschachtelte Strukturen leichter nachvollziehen lassen. Üblicherweise fügt sie Zeilenumbrüche und Einrückungen für Elemente wie SELECT-Listen, JOIN-Klauseln, WHERE-Bedingungen, Unterabfragen und CASE-Ausdrücke ein.

Das beabsichtigte Ergebnis der Abfrage sollte sich durch die Formatierung nicht ändern. SQL-Dialekte unterscheiden sich jedoch, und allein anhand der Formatierung lässt sich nicht zweifelsfrei feststellen, ob eine Anweisung ihre Bedeutung beibehalten hat. Prüfe den erzeugten SQL-Code, bevor du ihn mit Produktionsdaten ausführst. Das gilt insbesondere bei herstellerspezifischen Operatoren, prozeduralen Erweiterungen oder ungewöhnlichen Regeln für Anführungszeichen.

Ein Formatierer hilft dir, wenn du Abfragen anderer Personen liest, generierten SQL-Code prüfst, eine lange Anweisung debuggst oder Code für einen Pull Request vorbereitest. Ein einheitliches Layout erleichtert außerdem den Vergleich von Änderungen, da irrelevante Unterschiede bei den Abständen reduziert werden.

Wie verwende ich den SQL-Formatierer?

Füge die Anweisung in das Feld SQL ein oder gib sie dort ein. Sende sie anschließend ab, um die formatierte Version unter Verschönertes SQL zu erhalten. Die Eingabe wird zur Verarbeitung über HTTPS an den Server übertragen und nicht gespeichert.

1. Kopiere die vollständige Anweisung einschließlich aller benötigten Common Table Expressions. Prüfe im Ergebnis außerdem die Kommentare und ein gegebenenfalls vorhandenes abschließendes Semikolon.
2. Gib die Anweisung möglichst vollständig in das Feld SQL ein, statt nur einzelne Fragmente zu formatieren.
3. Lies das Ergebnis unter Verschönertes SQL sorgfältig durch. Achte besonders auf verschachtelte Ausdrücke und dialektspezifische Syntax.
4. Führe die formatierte Anweisung in einer geeigneten Entwicklungs- oder Staging-Umgebung aus, bevor du sie produktiv einsetzt.

Bei sensiblen Datenbankarbeiten solltest du die Richtlinien deiner Organisation prüfen, bevor du Abfragetext an ein serverbasiertes Tool übermittelst. Entferne Passwörter, Zugriffstoken, personenbezogene Daten und vertrauliche Literalwerte, wenn sie für das Verständnis der Abfrage nicht erforderlich sind.

Wie lese ich das formatierte SQL?

Orientiere dich beim Lesen an den Einrückungen und den Grenzen der einzelnen Klauseln. Betrachte das neue Layout nicht als Beleg dafür, dass die Anweisung gültig ist. SELECT, FROM, WHERE, GROUP BY und ORDER BY auf der obersten Ebene lassen sich meist leichter unterscheiden, sobald jeder logische Teil eine eigene Zeile oder Einrückungsebene erhält.

• Eingerückte Unterabfragen zeigen, an welcher Stelle ein inneres Ergebnis von einer äußeren Anweisung verwendet wird.
• Ausgerichtete Bedingungen erleichtern die Prüfung der Rangfolge von AND und OR. Standardmäßig hat AND Vorrang vor OR, und Klammern bestimmen weiterhin die logische Gruppierung.
• Getrennte JOIN-Klauseln machen deutlicher, welche ON-Bedingung zu welcher Tabelle gehört.
• Aufgegliederte SELECT-Listen helfen dabei, fehlende Kommas, doppelte Spalten und mehrdeutige Aliasnamen zu erkennen.
• Deutlich sichtbare CASE-Zweige erleichtern es, die Schlüsselwörter WHEN, THEN, ELSE und END einander zuzuordnen.

Zeichenketten in Anführungszeichen, Zahlen, Satzzeichen und Kommentare tragen in SQL zur Bedeutung bei. Prüfe sie daher genau, statt sie als rein darstellerische Elemente anzusehen. Zeichen mit Akzenten oder aus nichtlateinischen Schriftsystemen können je nach Datenbank und Zeichencodierung in Zeichenkettenliteralen und Bezeichnern in Anführungszeichen zulässig sein.

Kleine Formatierungsbeispiele

Betrachte zunächst diese kompakte Eingabe.

Eingabe: SELECT id,name FROM customers WHERE active=1 ORDER BY name;

Eine gut lesbare formatierte Version könnte so aussehen.

Ausgabe: SELECT id, name

FROM customers

WHERE active = 1

ORDER BY name;

Bei einer Abfrage mit einem Join sind Einrückungen noch hilfreicher.

Eingabe: SELECT o.id,c.name FROM orders o JOIN customers c ON c.id=o.customer_id WHERE o.total>100;

Eine gut lesbare Ausgabe könnte SELECT, FROM, JOIN, ON und WHERE jeweils in separate Zeilen setzen und dabei den Vergleich o.total > 100 beibehalten. Die genaue Groß- und Kleinschreibung, die Abstände und die Zeilenaufteilung unterscheiden sich je nach Formatierungskonvention. Verstehe diese Beispiele daher als mögliche Layouts und nicht als verbindlichen Stil.

Kann die Formatierung SQL-Fehler finden?

Nein. SQL übersichtlich zu formatieren ist nicht dasselbe, wie den Code mit dem Parser einer Datenbank zu validieren. Das ausgewiesene Ergebnis dieses Tools ist formatierter SQL-Code. Es sollte daher nicht als Syntaxprüfung, Schemaprüfung oder Werkzeug zur Ausführungsplanung verwendet werden.

Ein übersichtlicheres Layout kann bei der Prüfung dennoch mögliche Fehler sichtbar machen. Typische Beispiele sind ein fehlendes Komma in einer SELECT-Liste, nicht zusammenpassende Klammern, eine nicht abgeschlossene Zeichenkette in Anführungszeichen, ein JOIN ohne die vorgesehene Bedingung oder ein falsch gruppierter Ausdruck mit AND oder OR. Auch ein reserviertes Wort, das ohne Anführungszeichen als Bezeichner verwendet wird, fällt unter Umständen leichter auf.

Manche Probleme lassen sich nur mithilfe der Zieldatenbank feststellen. Eine von PostgreSQL akzeptierte Anweisung muss für Microsoft SQL Server, MySQL, Oracle Database oder SQLite möglicherweise angepasst werden. Fehlende Tabellen, unbekannte Spalten, inkompatible Datentypen und fehlende Berechtigungen können in der Regel nur von der Datenbank-Engine oder einem Entwicklungswerkzeug mit Unterstützung für den jeweiligen Dialekt diagnostiziert werden.

Wann lohnt sich die SQL-Formatierung nicht?

Eine Formatierung ist normalerweise unnötig, wenn der SQL-Code bereits einheitlich formatiert ist oder ausschließlich maschinell verarbeitet wird. Das Neuformatieren generierter Abfragen kann zahlreiche unerhebliche Änderungen in der Versionsverwaltung verursachen, ohne den Generator zu verbessern, der sie erzeugt hat.

Auch in den folgenden Situationen ist eine Formatierung möglicherweise nicht der richtige Schritt:

• Eine Migrationsdatei wurde signiert, mit einer Prüfsumme versehen oder wird auf andere Weise Byte für Byte verglichen.
• Eine minimierte oder kompakte Abfrage ist in ein größenkritisches Artefakt eingebettet und muss von niemandem geprüft werden.
• Bei der aktuellen Aufgabe geht es um Validierung, die Analyse des Ausführungsplans oder die Leistungsoptimierung und nicht um bessere Lesbarkeit.
• Die Abfrage enthält vertrauliche Werte, die gemäß den Richtlinien der Organisation nicht an einen serverbasierten Dienst gesendet werden dürfen.

Für eine reproduzierbare Formatierung eines gesamten Repositorys eignet sich unter Umständen ein Kommandozeilen-Formatierer mit Unterstützung für den jeweiligen Dialekt besser, da sich seine Konfiguration zusammen mit dem Code einchecken lässt. Bei strukturierten API-Nutzdaten, die SQL enthalten, kann der JSON-Validator & -Verschönerer dabei helfen, das umgebende JSON zu prüfen. Der SQL-Code selbst muss weiterhin SQL-spezifisch behandelt werden.

Häufig gestellte Fragen

Ändert die Formatierung, wie SQL mit NULL umgeht?

Nein. Leerzeichen und Einrückungen ändern weder die dreiwertige Logik von SQL noch das Verhalten von NULL. Prüfe trotzdem Ausdrücke wie column = NULL, für die in der Regel IS NULL erforderlich ist. Ein Formatierer korrigiert diesen semantischen Fehler nicht.

Kann ich mehrere SQL-Anweisungen auf einmal formatieren?

Eine Unterstützung für mehrere SQL-Anweisungen gleichzeitig ist nicht dokumentiert. Formatiere jede Anweisung einzeln.

Kann ich Kommentare bedenkenlos in der Eingabe lassen?

Nein, nicht ungeprüft. Kommentare können Verweise auf Tickets, interne Hostnamen, Kundendaten oder betriebliche Hinweise enthalten, selbst wenn der ausführbare SQL-Code keine sensiblen Literalwerte umfasst. Prüfe sowohl Zeilenkommentare als auch Blockkommentare, bevor du den Text an den Server sendest.

Sollte ich SQL-Schlüsselwörter groß- oder kleinschreiben?

Beide Schreibweisen sind im Allgemeinen zulässig, da viele Datenbank-Engines Schlüsselwörter ohne Anführungszeichen unabhängig von der Groß- und Kleinschreibung behandeln. Halte dich an die im Repository verwendete Konvention. Sei bei Bezeichnern in Anführungszeichen besonders vorsichtig, da manche Datenbanken deren Groß- und Kleinschreibung beibehalten oder unterscheiden.

Was sollte ich vor dem Ausführen der formatierten Abfrage prüfen?

Prüfe den SQL-Dialekt der Zieldatenbank, die WHERE- und JOIN-Bedingungen sowie bei UPDATE-, DELETE- und schemaändernden Anweisungen die Transaktionsgrenzen. Führe riskante Abfragen zuerst in einer Entwicklungs- oder Staging-Datenbank aus, vorzugsweise mit repräsentativen Daten und geeigneten Backups.