SQL-Formatierer & Verschoenerer

Nein. Der Formatter verändert nur Leerzeichen, Einrückungen und (optional) die Groß-/Kleinschreibung von Schlüsselwörtern. Die logische Struktur — Tabellennamen, Spaltennamen, Bedingungen, Joins, Ausdrücke — wird niemals verändert. Eine formatierte Abfrage liefert exakt dasselbe Ergebnis wie das Original, wenn sie auf einer Datenbank ausgeführt wird. Sie können die Abfrage sicher formatieren und dann in Ihre Anwendung kopieren, ohne das Risiko von Logikänderungen einzuführen.

Ja. Einzelzeilen-SQL-Kommentare (-- Kommentar bis zum Zeilenende) und Blockkommentare (/* mehrzeiliger Kommentar */) werden erkannt und im formatierten Ergebnis beibehalten. String-Literale (einfach angeführte Werte), zitierte Identifikatoren (Backtick oder Anführungszeichen, abhängig vom Dialekt) und numerische Literale werden alle korrekt behandelt — sie werden niemals über Zeilenumbrüche gesplittet oder während der Formatierung verändert. Verschachtelte Anführungszeichen und Escape-Zeichen innerhalb von Strings werden ebenfalls beibehalten.

Es gibt keine SQL-Standardanforderung — Schlüsselwörter funktionieren in den meisten Datenbanken in jeder Schreibweise. Die Verwendung von Großbuchstaben (SELECT, FROM, WHERE, JOIN) ist jedoch die überwältigend dominante Konvention im SQL-Code aus einem Hauptgrund: Lesbarkeit. Wenn Sie eine formatierte SQL-Abfrage scannen, stechen die Großbuchstaben der Schlüsselwörter gegenüber den Kleingeschriebenen Tabellen-/Spaltennamen hervor, wodurch die Struktur der Abfrage sofort erkennbar wird. Dieses Tool verwendet standardmäßig Großbuchstaben für Schlüsselwörter, was der Konvention in den meisten SQL-Styleguides entspricht, einschließlich der von Google, GitLab und Kickstarter.

Ja, für allgemeine Formatierungszwecke. Die Kern-SQL-Syntax (SELECT, JOIN, WHERE usw.) ist über MySQL, PostgreSQL, SQLite, SQL Server und Oracle hinweg standardisiert. Datenbankspezifische Syntax wird in der Regel akzeptiert, aber möglicherweise nicht perfekt formatiert — zum Beispiel das PostgreSQL-spezifische :: Typcasting, SQL Server T-SQL-spezifische Funktionen oder die MySQL LIMIT/OFFSET-Syntax. Wenn Sie bei dialektspezifischem Code eine unerwartete Formatierung sehen, ist die Logik dennoch korrekt — nur die Darstellung der Einrückung kann variieren.

Unformatierte SQL ist eine häufige Quelle für übersehene Bugs in Code Reviews. Wenn eine Abfrage in einer einzigen langen Zeile steht, ist es leicht, eine fehlende JOIN-Bedingung (die zu einem kartesischen Produkt führt), eine versehentlich ausgelassene WHERE-Klausel (die alle Zeilen betrifft) oder eine falsche Priorität bei AND/OR-Bedingungen zu übersehen. Formatiertes SQL setzt jede Klausel und Bedingung in eine eigene Zeile, wodurch strukturelle Fehler visuell deutlich werden. Viele Teams verlangen aus genau diesem Grund, dass SQL vor der Überprüfung formatiert wird.

Basis-Multi-Statement-SQL (mehrere SELECT- oder INSERT-Anweisungen, die durch Semikolons getrennt sind) wird unterstützt — jede Anweisung wird unabhängig formatiert. Gespeicherte Prozeduren, PL/pgSQL, T-SQL-Blöcke mit BEGIN/END und komplexe prozedurale SQL werden jedoch möglicherweise nicht sauber formatiert, da sich der Formatter auf Standard-DML/DDL-Anweisungen konzentriert. Bei gespeicherten Prozeduren versuchen Sie, einzelne Anweisungen innerhalb des Prozedurkörpers zu formatieren, anstatt die gesamte Prozedurdefinition.

Nein. Die gesamte Formatierung läuft in Ihrem Browser mittels JavaScript. Ihre SQL-Abfragen, einschließlich aller Tabellennamen, Spaltennamen, Datenwerte oder Verbindungszeichenfolgen in der Abfrage, verlassen niemals Ihr Gerät. Dies macht es sicher, Produktionsabfragen zu formatieren, die echte Datenreferenzen oder proprietäre Schema-Informationen enthalten.