SQL-formatter
Formatteer en verfraai SQL-query's. Plak rommelige SQL en krijg schone, ingesprongen uitvoer met syntaxiskleuring.
Belangrijkste functies
- Automatisch keywords in hoofdletters zetten
- Instelbare inspringing
- Syntaxismarkering
- Ondersteuning voor veelvoorkomende SQL-dialecten
Guide
SQL-formatting transformeert dichte, onleesbare queries in gestructureerde, consistent ingesprongen code die gemakkelijk te lezen, beoordelen, debuggen en onderhouden is. Een query die perfect werkt wanneer hij als één regel wordt geschreven, wordt een onderhoudslast wanneer iemand anders (of jij, drie maanden later) moet begrijpen wat hij doet. Consistente SQL-formatting is geen cosmeticum. Het vermindert bugs, versnelt code-review en maakt complexe queries beheersbaar. Deze gids behandelt opmaakconventies, clausulestructuur, veelvoorkomende patronen voor verschillende querytypes en hoe formatting samenwerkt met queryoptimalisatie. De fundamentele regel van SQL-formatting is één clausule per regel. SELECT, FROM, WHERE, JOIN, ON, GROUP BY, HAVING, ORDER BY, LIMIT, INSERT INTO, VALUES, UPDATE, SET en DELETE FROM beginnen elk op hun eigen regel op het basis-inspringingsniveau. Deze structuur maakt de query scanbaar. Je kunt in één oogopslag zien welke kolommen worden geselecteerd, welke tabellen betrokken zijn, welke voorwaarden de gegevens filteren en hoe de resultaten worden geordend. Een op deze manier geformatteerde query leest als een gestructureerd document in plaats van een doorlopende zin. SELECT-clausule-opmaak somt elke kolom op zijn eigen regel op, één niveau ingesprongen van het SELECT-sleutelwoord. Leidende komma's (komma's aan het begin van elke regel in plaats van het einde) zijn een populaire conventie omdat ze het gemakkelijk maken om individuele kolommen uit te commentariëren en schonere diffs produceren in versiebeheer. Zowel afsluitende als leidende komma's zijn acceptabel zolang de keuze consistent is over de codebasis. Kolomaliasen moeten het AS-sleutelwoord expliciet gebruiken (column_name AS alias) in plaats van de shorthand (column_name alias) voor duidelijkheid. Is een kolomexpressie lang (een CASE-statement of een functieaanroep met meerdere argumenten), plaats deze dan op zijn eigen regel en spring de voortzetting in. FROM- en JOIN-clausules profiteren van consistente uitlijning. Elke JOIN krijgt zijn eigen regel op dezelfde inspringing als FROM. De ON-voorwaarde wordt ingesprongen onder zijn JOIN. Voor queries met veel joins maakt deze visuele structuur de tabrelaties duidelijk: FROM orders o JOIN customers c ON c.customer_id = o.customer_id JOIN products p ON p.product_id = o.product_id LEFT JOIN shipping s ON s.order_id = o.order_id Het join-type (INNER JOIN, LEFT JOIN, RIGHT JOIN, CROSS JOIN, FULL OUTER JOIN) draagt betekenis. Opmaak die elke join visueel scheidt helpt reviewers verifiëren dat het juiste join-type wordt gebruikt voor elke relatie. Een LEFT JOIN die een INNER JOIN zou moeten zijn (of omgekeerd) is een veelvoorkomende bug die geformatteerde code gemakkelijker te ontdekken maakt. WHERE-clausule-opmaak plaatst elke voorwaarde op zijn eigen regel met AND of OR aan het begin van de regel. Voorwaarden onder WHERE inspringen maakt de filterlogica zichtbaar: WHERE o.order_date >= '2026-01-01' AND o.status = 'completed' AND c.country = 'US' AND (p.category = 'electronics' OR p.category = 'appliances') Complexe booleaanse logica met gemengde AND- en OR-operatoren is een veelvoorkomende bron van bugs. Opmaak met expliciete haakjes en duidelijke inspringing toont de logische groepering. Zonder formatting is WHERE a = 1 AND b = 2 OR c = 3 ambigu voor menselijke lezers (hoewel SQL AND evalueert voor OR, dus het betekent (a = 1 AND b = 2) OR c = 3). Geformatteerd met haakjes wordt de bedoeling duidelijk. Gebruik altijd haakjes met gemengde AND/OR om voorrang expliciet te maken. Subqueries moeten één niveau binnen hun haakjes worden ingesprongen. Elke subquery wordt geformatteerd met dezelfde regels als een query op topniveau. Gecorreleerde subqueries (degenen die verwijzen naar kolommen uit de buitenste query) zijn bijzonder belangrijk om duidelijk te formatteren omdat hun relatie tot de buitenste query hun gedrag bepaalt: SELECT customer_name , total_spent FROM customers c WHERE total_spent > ( SELECT AVG(total_spent) FROM customers WHERE country = c.country ) De inspringing toont dat de subquery binnen de WHERE-clausule is genest en verwijst naar c.country uit de buitenste query. Voor diep geneste subqueries (drie of meer niveaus), overweeg te refactoren naar CTE's in plaats daarvan, want diepe nesting wordt moeilijk te volgen ongeacht formatting. Common Table Expressions (CTE's) die WITH-clausules gebruiken moeten worden geformatteerd met elke CTE als een apart benoemd blok: WITH monthly_sales AS ( SELECT DATE_TRUNC('month', order_date) AS month , SUM(amount) AS total FROM orders GROUP BY DATE_TRUNC('month', order_date) ), monthly_avg AS ( SELECT AVG(total) AS avg_total FROM monthly_sales ) SELECT m.month , m.total , a.avg_total FROM monthly_sales m CROSS JOIN monthly_avg a WHERE m.total > a.avg_total CTE's zijn een van de krachtigste SQL-functies voor het opbreken van complexe queries in leesbare, testbare componenten. Elke CTE kan onafhankelijk worden getest door alleen zijn SELECT-statement uit te voeren. Juiste formatting maakt het doel van elke CTE zichtbaar en de gegevensstroom tussen CTE's traceerbaar. Benoem je CTE's beschrijvend: monthly_sales is beter dan cte1. GROUP BY- en ORDER BY-clausules volgen hetzelfde meerregelige patroon als SELECT wanneer ze verwijzen naar meerdere kolommen. Som elke kolom op zijn eigen ingesprongen regel op. Voor GROUP BY maakt dit het gemakkelijk om te verifiëren dat alle niet-geaggregeerde SELECT-kolommen zijn inbegrepen (een vereiste in standaard SQL en afgedwongen door PostgreSQL, hoewel MySQL standaard toegeeflijk is). Voor ORDER BY verduidelijkt het opsommen van elke sorteerkolom met zijn richting (ASC of DESC) op een aparte regel de sorteerprioriteit. ASC expliciet vermelden (zelfs hoewel het de standaard is) verbetert de leesbaarheid. HAVING-clausule-opmaak volgt dezelfde regels als WHERE. HAVING filtert groepen na aggregratie en zijn voorwaarden moeten worden geformatteerd met één voorwaarde per regel. Een veelvoorkomende opmaakfout is het plaatsen van HAVING-voorwaarden in de WHERE-clausule of omgekeerd. WHERE filtert rijen voor groepering. HAVING filtert groepen na aggregratie. Correcte plaatsing is essentieel voor zowel correctheid als prestaties en duidelijke formatting maakt het gemakkelijk om te verifiëren. CASE-expressies zijn meerregelige constructies die moeten worden geformatteerd om elk WHEN/THEN-paar te tonen: SELECT order_id , CASE WHEN status = 'shipped' THEN 'In Transit' WHEN status = 'delivered' THEN 'Complete' WHEN status = 'returned' THEN 'Returned' ELSE 'Processing' END AS status_label FROM orders Geneste CASE-expressies (CASE binnen CASE) moeten waar mogelijk worden vermeden omdat ze onleesbaar worden ongeacht formatting. Refactor in plaats daarvan naar CTE's, berekende kolommen of een opzoektabel die in de query wordt gejoind. INSERT-statements hebben twee veelvoorkomende formaten. Voor inserties van één rij met benoemde kolommen, som elk kolom-waarde-paar leesbaar op: INSERT INTO customers ( customer_name , email , country , created_at ) VALUES ( 'John Doe' , 'john@example.com' , 'US' , CURRENT_TIMESTAMP ) De VALUES-vermeldingen uitlijnen met hun overeenkomstige kolomnamen maakt het gemakkelijk om te verifiëren dat elke waarde overeenkomt met de juiste kolom. Voor INSERT...SELECT-statements, formatteer het SELECT-gedeelte met behulp van standaard SELECT-opmaakregels. UPDATE-statements profiteren van het formatteren van elke SET-toewijzing op zijn eigen regel: UPDATE customers SET email = 'newemail@example.com' , updated_at = CURRENT_TIMESTAMP , status = 'verified' WHERE customer_id = 12345 Deze structuur maakt duidelijk welke kolommen worden gewijzigd en voorkomt het per ongeluk weglaten van de WHERE-clausule, die elke rij in de tabel zou bijwerken. De WHERE-clausule in UPDATE- en DELETE-statements is de meest kritieke clausule om correct te krijgen. Opmaak die de WHERE op zijn eigen regel plaatst op hetzelfde niveau als UPDATE of DELETE maakt zijn aanwezigheid (of afwezigheid) duidelijk. DELETE-statements moeten hun WHERE-clausule altijd duidelijk zichtbaar hebben: DELETE FROM order_items WHERE order_id = 12345 AND item_status = 'cancelled' Een DELETE zonder WHERE verwijdert alle rijen uit de tabel. Geformatteerde code maakt de aan- of afwezigheid van WHERE direct zichtbaar. Sommige teams nemen een conventie aan om DELETE-queries altijd eerst als SELECT-queries te schrijven (DELETE FROM vervangen door SELECT * FROM) om te verifiëren welke rijen zullen worden beïnvloed, vervolgens terug te converteren naar DELETE. Window-functies zijn een van de meest complexe SQL-constructies om te formatteren. De OVER-clausule met PARTITION BY en ORDER BY moet op zijn eigen ingesprongen regels wanneer ze lang zijn: SELECT customer_id , order_date , amount , SUM(amount) OVER ( PARTITION BY customer_id ORDER BY order_date ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW ) AS running_total FROM orders Voor korte window-specificaties is het op één regel houden acceptabel: ROW_NUMBER() OVER (ORDER BY id) AS row_num. Het doel is leesbaarheid op de lengte en complexiteit van de werkelijke expressie. Benoemde window-definities (WINDOW w AS (PARTITION BY customer_id ORDER BY order_date)) gevolgd door OVER w verminderen herhaling wanneer meerdere kolommen dezelfde window-specificatie gebruiken. Sleutelwoord-hoofdlettergebruik is een stijlkeuze met sterke meningen aan beide kanten. SLEUTELWOORDEN IN HOOFDLETTERS (SELECT, FROM, WHERE) onderscheiden visueel SQL-syntaxis van tabel- en kolomnamen. Sleutelwoorden in kleine letters vallen weg maar zijn gemakkelijker te typen. Het belangrijkste is consistentie. Kies één conventie en handhaaf deze over het team. Veel organisaties gebruiken hoofdletters voor sleutelwoorden en kleine letters voor identifiers. Sommige moderne stijlgidsen verkiezen alles in kleine letters, argumenterend dat syntaxisaccentuering in editors sleutelwoorden al onderscheidt van identifiers. Een derde benadering kapitaliseert alleen de belangrijkste clausule-sleutelwoorden (SELECT, FROM, WHERE) en laat functienamen en minder belangrijke sleutelwoorden in kleine letters. Tabelaliasen moeten betekenisvol zijn. Aliasen van één letter (a, b, c) gebruiken bespaart typen maar maakt queries moeilijker te lezen, in het bijzonder bij veel joins. Korte afkortingen afgeleid van de tabelnaam zijn beter: customers AS c, orders AS o, order_items AS oi. In complexe queries met veel tabellen verbeteren langere aliasen de duidelijkheid: customers AS cust, order_items AS items. Gebruik altijd het AS-sleutelwoord voor aliasen om ze te onderscheiden van typefouten of vergeten komma's. Gebruik nooit gereserveerde woorden als alias. Inspringingsbreedte moet consistent zijn. Twee spaties en vier spaties zijn beide veelvoorkomende keuzes. Tabs versus spaties is een voorkeur, maar spaties produceren meer consistente uitlijning over editors en hulpmiddelen. Het SQL-formatterprogramma laat je de inspringingsbreedte configureren om de standaard van je team te matchen. Welke breedte je ook kiest, gebruik deze uniform voor alle inspringingsniveaus: clausule-body, subquery-nesting, CASE-expressie-bodies en CTE-definities. Commentaar-opmaak in SQL gebruikt -- voor commentaar van één regel en /* */ voor commentaar van meerdere regels. Plaats commentaar boven de clausule of expressie die ze beschrijven, niet inline aan het einde van een lange regel waar ze mogelijk worden gemist. Voor complexe bedrijfslogica in WHERE-clausules is commentaar dat uitlegt waarom een voorwaarde bestaat waardevol: -- Testaccounts aangemaakt door het QA-team uitsluiten vóór de filtervoorwaarde. Commentaar dat de SQL herhaalt (-- Tabel customers joinen) voegt ruis toe zonder waarde. Goed commentaar legt intentie uit, niet mechaniek. Opmaak en queryprestaties zijn niet direct gerelateerd. De database-engine parseert en optimaliseert de query ongeacht witruimte en regeleinden. Echter, goed geformatteerde queries zijn gemakkelijker te optimaliseren omdat je de structuur duidelijk kunt zien. Een slecht geformatteerde query met een prestatieprobleem verbergt het probleem in een muur van tekst. Dezelfde query, correct geformatteerd, onthult de problematische subquery, ontbrekende join-voorwaarde, onnodige DISTINCT of niet-sargable WHERE-clausule in één oogopslag. Formatting is een debugging- en optimalisatiehulpmiddel. Versiebeheer en SQL-formatting wisselen wisselwerking op belangrijke manieren. Een hele query herformatteren in één commit produceert een diff die elke regel aanraakt, wat het onmogelijk maakt om te zien wat er daadwerkelijk veranderd is. Bij het aannemen van een formatter voor een bestaande codebasis, doe de formatting in een toegewijde commit met een duidelijke boodschap zoals "SQL-opmaakstandaard toepassen." Latere wijzigingen produceren vervolgens schone, betekenisvolle diffs. Leidende komma's zijn deels populair omdat het toevoegen van een nieuwe kolom aan een SELECT een diff van één regel produceert (de nieuwe regel), terwijl afsluitende komma's vereisen dat de vorige regel wordt gewijzigd om een komma toe te voegen, wat een diff van twee regels creëert. Dialectverschillen beïnvloeden opmaakkeuzes. PostgreSQL, MySQL, SQL Server, Oracle, SQLite en BigQuery hebben elk syntaxisvariaties. PostgreSQL gebruikt dubbele-dubbelepunt-casting (value::type) en dollar-aangehaalde tekenreeksen. MySQL gebruikt backtick-aanhaling voor identifiers en LIMIT met OFFSET. SQL Server gebruikt vierkante-haakjes-aanhaling, TOP in plaats van LIMIT en CROSS APPLY in plaats van LATERAL JOIN. Oracle gebruikt ROWNUM, CONNECT BY voor hiërarchische queries en verschillende datumfuncties. BigQuery gebruikt backtick-aanhaling voor project-gekwalificeerde tabelnamen. Een formatter moet het dialect verwerken dat je team gebruikt. Het SQL-formatterprogramma ondersteunt standaard SQL-syntaxis die compatibel is met alle belangrijke dialecten. Teamadoptie van SQL-opmaakstandaarden vereist een gedeelde configuratie en idealiter geautomatiseerde handhaving. Neem SQL-opmaakregels op in je codestijlgids. Gebruik pre-commit-hooks of CI-controles om formatting op SQL-bestanden te verifiëren. Definieer de standaard in een hulpmiddel-configuratiebestand (zoals .sql-formatter.json) dat wordt gecommit naar de repository. De initiële kosten van het overeenkomen van een standaard worden terugbetaald door elke code-review die geen opmaak-gezever meer bevat en elke debugging-sessie die begint met leesbare code in plaats van een herformattingsoefening. SQL in toepassingscode (ingesloten in Python, JavaScript, Java of andere talen) vormt aanvullende opmaakuitdagingen. Een onbewerkte SQL-tekenreeks in een Python-functie of een JavaScript-template-literal is onderworpen aan zowel de opmaakregels van de hosttaal als SQL-opmaakregels. Meerregelige tekenreeksliteralen (Python-triple-aanhalingstekens, JavaScript-backticks) laten je SQL-opmaak binnen toepassingscode behouden. Scheid de SQL-tekenreeks van de toepassingslogica: wijs de query toe aan een benoemde constante (const FIND_ACTIVE_USERS = ...) en verwijs ernaar waar nodig. Voor grote queryverzamelingen, verplaats SQL naar aparte .sql-bestanden en laad ze bij uitvoering. ORM-gegenereerde SQL heeft vaak formatting nodig voor debugging. Produceert je Django-, SQLAlchemy-, ActiveRecord- of Prisma-query onverwachte resultaten, dan helpt het bekijken van de gegenereerde SQL het probleem te diagnosticeren. De meeste ORM's bieden een manier om de onbewerkte SQL uit te voeren (query.toString() in Knex, str(query) in SQLAlchemy, .explain() in Django). Plak de gegenereerde SQL in een formatter om zijn structuur te begrijpen. ORM-gegenereerde SQL is typisch dicht en moeilijk te lezen omdat hij nooit voor mensen bedoeld was. Geformatteerde uitvoer maakt de joins, voorwaarden en subqueries zichtbaar. Opgeslagen procedures en functies vereisen opmaakdiscipline verder dan individuele queries. Elke procedure bevat meerdere SQL-statements, variabeledeclaraties, controlestroom (IF/ELSE, WHILE, FOR) en uitzonderingsafhandeling (TRY/CATCH, BEGIN/EXCEPTION). Formatteer elk SQL-statement binnen de procedure met behulp van de standaard query-opmaakregels. Spring controlestroom-bodies één niveau in van hun sleutelwoorden. Plaats BEGIN en END op hun eigen regels. Voeg lege regels toe tussen logische secties binnen de procedure. Goed geformatteerde opgeslagen procedures zijn dramatisch gemakkelijker te debuggen dan dichte, ongeformatteerde. Migratiebestanden profiteren van SQL-formatting omdat ze worden beoordeeld in pull-requests en permanente databaseschemawijzigingen vertegenwoordigen. Een CREATE TABLE-statement met geformatteerde kolomdefinities is gemakkelijk te beoordelen op correcte gegevenstypes, beperkingen, nullability en standaardwaarden. Een ALTER TABLE met meerdere ADD COLUMN-statements moet elke kolom op zijn eigen regel opsommen. Formatting maakt migratiebeoordeling sneller en verkleint de kans op het shippen van een migratie met onjuiste kolomtypes of ontbrekende beperkingen. Prestatieanalyse-queries (EXPLAIN, EXPLAIN ANALYZE) produceren uitvoer die gemakkelijker te correleren is met de query wanneer de query zelf is geformatteerd. Plak je een query van één regel in EXPLAIN ANALYZE, dan verwijst de uitvoer naar bewerkingen op specifieke querycomponenten die moeilijk te lokaliseren zijn in de tekenreeks van één regel. Dezelfde query, correct geformatteerd, laat je elke regel van het uitvoeringsplan matchen met de overeenkomstige clausule in de query. Deze correlatie is essentieel voor het identificeren welke join of subquery prestatieproblemen veroorzaakt. Dynamische SQL-generatie in toepassingscode moet geformatteerde uitvoer produceren. Bij het programmatisch bouwen van queries (SQL-tekenreeksen construeren op basis van gebruikersinvoer of configuratie), voeg nieuwe regels en inspringing toe aan de gegenereerde query. Dit kost niets bij uitvoering maar maakt logging en debugging dramatisch gemakkelijker. Veroorzaakt een gegenereerde query een fout of presteert deze slecht, dan kun je de geformatteerde SQL in het logboek lezen en onmiddellijk de structuur begrijpen. Alles samenvoegen tot één regel bespaart een paar tekens maar creëert debugging-hoofdpijn. SQL-code-review-checklists profiteren van opmaakstandaarden. Een reviewer die geformatteerde SQL controleert kan systematisch verifiëren: correcte join-types voor elke tabelrelatie, WHERE-clausule-voorwaarden die overeenkomen met de bedrijfsvereiste, GROUP BY inclusief alle niet-geaggregeerde kolommen, ORDER BY die de verwachte sortering weerspiegelt, passend gebruik van LEFT JOIN versus INNER JOIN (een LEFT JOIN waar INNER volstaat wijst op een bug of onnodige voorzichtigheid) en afwezigheid van veelvoorkomende anti-patronen zoals SELECT * in productiecode, impliciete cross-joins en gecorreleerde subqueries die als joins kunnen worden herschreven. Het formatteren van grote legacy-queries is een van de meest waardevolle toepassingen van een SQL-formatter. Enterprise-databases hopen queries op over jaren of decennia. Queries geschreven door ontwikkelaars die allang het bedrijf hebben verlaten, meerdere keren gewijzigd en nooit geherformatteerd worden muren van tekst die niemand durft aan te raken. Deze queries door een formatter draaien is de eerste stap om ze onderhoudbaar te maken. Formatteer de query, commit de opmaakwijziging apart, begin vervolgens het daadwerkelijke wijzigingswerk met een leesbaar startpunt. Het SQL-formatterprogramma neemt elke geldige SQL-query, parseert zijn structuur en voert consistent geformatteerde SQL uit volgens configureerbare regels voor inspringing, sleutelwoordhoofdletter en clausuleplaatsing. Plak je query, klik op formatteren en kopieer het resultaat. Gebruik het voor het formatteren van queries voor het committen, het opschonen van legacy-SQL voor beoordeling, het standaardiseren van queries ontvangen van collega's of gegenereerd door ORM-hulpmiddelen en het voorbereiden van SQL voor documentatie of presentaties.
Veelgestelde vragen
Welke SQL-dialecten worden ondersteund?
De formatter ondersteunt standaard SQL-syntax, waaronder SELECT, JOIN, WHERE, GROUP BY en andere veelvoorkomende clausules.
Wijzigt het mijn query-logica?
Nee, de formatter wijzigt alleen witruimte en hoofdlettergebruik. Je query-logica blijft exact hetzelfde.
