SQL formatter/beautifier

De SQL formatter/beautifier is een gratis tool die SQL-code omzet in een beter leesbare versie met een consistente opmaak.

Wat verandert er bij het formatteren van SQL?

SQL formatteren verandert de presentatie van een query, zodat de clausules, expressies en geneste structuren makkelijker te volgen zijn. Meestal worden regeleinden en inspringingen toegevoegd rond onderdelen zoals SELECT-lijsten, JOIN-clausules, WHERE-voorwaarden, subquery's en CASE-expressies.

De opmaak hoort niets te veranderen aan het beoogde resultaat van de query. SQL-dialecten verschillen echter, en formattering alleen kan niet aantonen dat een statement dezelfde betekenis heeft behouden. Controleer de gegenereerde SQL voordat je die op productiegegevens uitvoert, vooral bij leverancierspecifieke operators, procedurele uitbreidingen of ongebruikelijke regels voor aanhalingstekens.

Een formatter is handig als je query's van anderen leest, gegenereerde SQL beoordeelt, een lang statement debugt of code voorbereidt voor een pull request. Een consistente opmaak maakt wijzigingen ook makkelijker te vergelijken, doordat irrelevante verschillen in witruimte afnemen.

Hoe gebruik ik de SQL-formatter?

Plak of typ het statement in het veld SQL en verstuur het om de geformatteerde versie in Opgemaakte SQL te ontvangen. De invoer wordt voor verwerking via HTTPS naar de server verzonden en niet opgeslagen.

1. Kopieer het volledige statement, inclusief eventuele common table expressions die behouden moeten blijven. Controleer in het resultaat ook de opmerkingen en een eventuele afsluitende puntkomma.
2. Voer het waar mogelijk als geheel in het veld SQL in, in plaats van losse fragmenten afzonderlijk te formatteren.
3. Lees het resultaat in Opgemaakte SQL en let vooral op geneste expressies en dialectspecifieke syntaxis.
4. Voer het geformatteerde statement uit in een geschikte ontwikkel- of testomgeving voordat je het implementeert.

Werk je met gevoelige databasegegevens, controleer dan eerst het beleid van je organisatie voordat je querytekst naar een servertool stuurt. Verwijder wachtwoorden, toegangstokens, persoonsgegevens en vertrouwelijke letterlijke waarden als die niet nodig zijn om de query te begrijpen.

Hoe lees ik de geformatteerde SQL?

Volg bij het lezen de inspringing en de grenzen tussen clausules. Beschouw de nieuwe opmaak niet als bewijs dat het statement geldig is. Een SELECT, FROM, WHERE, GROUP BY en ORDER BY op het hoogste niveau zijn meestal makkelijker van elkaar te onderscheiden wanneer elk logisch onderdeel een eigen regel of inspringniveau heeft.

• Ingesprongen subquery's laten zien waar een binnenste resultaat door een buitenste statement wordt gebruikt.
• Uitgelijnde voorwaarden maken de voorrang van AND en OR makkelijker te controleren. Standaard heeft AND voorrang op OR, terwijl haakjes nog steeds de logische groepering bepalen.
• Afzonderlijke JOIN-clausules maken duidelijker welke ON-voorwaarde bij elke tabel hoort.
• Uitgeschreven SELECT-lijsten maken ontbrekende komma's, dubbele kolommen en dubbelzinnige aliassen makkelijker zichtbaar.
• Duidelijk weergegeven CASE-takken helpen bij het koppelen van de trefwoorden WHEN, THEN, ELSE en END.

Tekst tussen aanhalingstekens, getallen, leestekens en opmerkingen hebben betekenis in SQL. Controleer ze dus en ga er niet van uit dat ze alleen voor de presentatie dienen. Tekens met accenten en niet-Latijnse tekens kunnen geldig zijn binnen tekenreeksliteralen en identifiers tussen aanhalingstekens, afhankelijk van de database en de gebruikte tekencodering.

Kleine voorbeelden van SQL-opmaak

Neem deze compacte invoer.

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

Een leesbaar geformatteerde versie kan er als volgt uitzien.

Uitvoer: SELECT id, name

FROM customers

WHERE active = 1

ORDER BY name;

Bij een query met een join levert inspringing nog meer voordeel op.

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

In leesbare uitvoer kunnen SELECT, FROM, JOIN, ON en WHERE elk op een aparte regel staan, terwijl de vergelijking o.total > 100 behouden blijft. Het exacte gebruik van hoofdletters, spaties en regeleinden verschilt per opmaakconventie. Zie deze voorbeelden daarom als mogelijke indelingen, niet als een gegarandeerde huisstijl.

Kan formattering SQL-fouten vinden?

Nee, SQL opmaken is niet hetzelfde als de code valideren met de parser van een database. Het aangegeven resultaat van deze tool is geformatteerde SQL. Gebruik de tool daarom niet als syntaxiscontrole, schemacontrole of planner voor query-uitvoering.

Een duidelijkere opmaak kan tijdens een controle wel waarschijnlijke fouten aan het licht brengen. Denk aan een ontbrekende komma in een SELECT-lijst, haakjes zonder bijbehorend openings- of sluitingsteken, een tekenreeks zonder afsluitend aanhalingsteken, een JOIN zonder de bedoelde voorwaarde of een verkeerd gegroepeerde expressie met AND of OR. Ook kan een gereserveerd woord dat zonder aanhalingstekens als identifier wordt gebruikt, makkelijker opvallen.

Sommige problemen zijn alleen vast te stellen met de doeldatabase. Een statement dat PostgreSQL accepteert, moet mogelijk worden aangepast voor Microsoft SQL Server, MySQL, Oracle Database of SQLite. Voor ontbrekende tabellen, onbekende kolommen, incompatibele gegevenstypen en problemen met machtigingen is doorgaans de database-engine of een dialectspecifieke ontwikkeltool nodig.

Wanneer heeft SQL formatteren weinig nut?

Formatteren is meestal niet nodig als de SQL al consequent is opgemaakt of alleen door een machine wordt verwerkt. Het opnieuw formatteren van gegenereerde query's kan veel irrelevante wijzigingen in versiebeheer veroorzaken, zonder de generator te verbeteren die ze heeft gemaakt.

Ook in de volgende situaties is formatteren mogelijk niet de juiste stap:

• Een migratiebestand is ondertekend, van een checksum voorzien of wordt anderszins byte voor byte vergeleken.
• Een geminimaliseerde of compacte query is opgenomen in een bestand waarbij grootte belangrijk is en niemand de query hoeft te beoordelen.
• De directe taak draait om validatie, analyse van het uitvoeringsplan of prestatieoptimalisatie, niet om leesbaarheid.
• De query bevat vertrouwelijke waarden die volgens het beleid van de organisatie niet naar een serverdienst mogen worden verzonden.

Voor herhaalbare formattering van een volledige repository kan een dialectspecifieke commandlineformatter geschikter zijn, omdat je de configuratie samen met de code kunt vastleggen. Bij gestructureerde API-payloads die SQL bevatten, kan de JSON-validator & -verfraaier helpen om de omringende JSON te controleren. De SQL zelf moet nog steeds met een SQL-specifieke tool worden verwerkt.

Veelgestelde vragen

Verandert formatteren de werking van NULL?

Witruimte en inspringing veranderen niets aan de driewaardige logica van SQL of aan de werking van NULL. Controleer desondanks expressies zoals column = NULL, waarvoor meestal IS NULL nodig is. Een formatter herstelt die semantische fout niet.

Kan ik meerdere SQL-statements tegelijk formatteren?

Ondersteuning voor meerdere SQL-statements tegelijk is niet gedocumenteerd. Formatteer elk statement afzonderlijk.

Kan ik opmerkingen veilig in de invoer laten staan?

Opmerkingen kunnen verwijzingen naar tickets, interne hostnamen, klantgegevens of operationele notities bevatten, zelfs wanneer de uitvoerbare SQL geen gevoelige letterlijke waarden bevat. Controleer zowel regelcommentaar als blokcommentaar voordat je de tekst naar de server stuurt.

Moeten SQL-trefwoorden met hoofdletters of kleine letters?

Beide stijlen zijn doorgaans aanvaardbaar, omdat veel database-engines bij trefwoorden zonder aanhalingstekens geen onderscheid maken tussen hoofdletters en kleine letters. Volg de conventie van de repository en let goed op identifiers tussen aanhalingstekens. Sommige databases behouden hun hoofdlettergebruik of maken daarin onderscheid.

Wat moet ik controleren voordat ik de geformatteerde query uitvoer?

Controleer het dialect van de doeldatabase, bekijk de WHERE- en JOIN-voorwaarden en verifieer de transactiegrenzen voor UPDATE, DELETE en statements die het schema wijzigen. Voer riskante query's eerst uit in een ontwikkel- of testdatabase, bij voorkeur met representatieve gegevens en geschikte back-ups.