SQL-query's formatteren _

Hoe SQL-opmaak werkt

SQL-opmaak is een lexer-gestuurde herschrijving die elk token in de query doorloopt en er witruimte omheen plaatst op basis van de regels van het gekozen dialect. De querysemantiek verandert nooit, alleen de opmaak.

1. Kies een dialect. MySQL-backticks, PostgreSQL ::-casts, BigQuery-tabelpadnotatie met punten en T-SQL-blokhaken om identificatoren vereisen elk een tokenizer die ze herkent. De dialectkiezer bepaalt welke grammatica wordt toegepast.
2. Tokeniseer de invoer. De formatter splitst de query op in een stroom tokens: trefwoorden (SELECT, JOIN), identificatoren, literals, operatoren, haakjes en opmerkingen. Stringliterals en geciteerde identificatoren worden ongewijzigd doorgegeven zodat dialectspecifieke syntaxis blijft werken.
3. Pas layoutregels toe. Clausules op het hoogste niveau (SELECT, FROM, WHERE, GROUP BY, ORDER BY) beginnen op een eigen regel. Door komma's gescheiden uitdrukkingen in de selectielijst en kolomlijsten krijgen elk een regel, ingesprongen met de gekozen inspringing.
4. Pas trefwoordhoofdletters toe. De trefwoordschakelaar herschrijft herkende SQL-trefwoorden naar hoofdletters, kleine letters of behoudt de invoerhoofdletters ongewijzigd. Identificatoren worden nooit aangeraakt — kolom- en tabelnamen komen altijd door zoals ze zijn geschreven.
5. Geef de opgemaakte string terug. De tokenstroom wordt samengevoegd tot één string met het inspringteken (2 spaties, 4 spaties of tab) en de geconfigureerde regelafbrekingregel. Live-modus herstart de hele pijplijn met een debounce van 200 ms terwijl je typt.

Waarom SQL pretty-printen

• Leesbaarheid van pull-request diffs. Een CTE van 200 regels herschreven als één regel maakt een code-review onmogelijk. Consistente opmaak beperkt de diff tot de wijziging die je daadwerkelijk hebt aangebracht — een nieuwe kolom, een extra JOIN, een ander WHERE-predikaat — zodat de reviewer het kan zien zonder witruimte te moeten ontwarren.
• Gemakkelijker debuggen. Als een query het verkeerde aantal rijen teruggeeft, lees je hem regel voor regel. Opgemaakte SQL plaatst elke JOIN op een eigen regel en lijnt WHERE-predikaten uit zodat een ontbrekende AND of een onjuiste OR direct opvalt.
• Consistente teamstijl. De meeste teams hanteren een SQL-stijlgids (dbt Labs, GitLab en Mode Analytics publiceren allemaal de hunne) en willen dat elke gecommitte query hem volgt. Een formatter die vóór commit draait, haalt het stijldiscussie uit de review en laat alleen de logica over om te bespreken.
• SQL delen in documentatie. Draaiboeken, incident-retro's en Notion-documenten profiteren allemaal van SQL die van boven naar beneden leesbaar is. Opgemaakte SQL plakt netjes in een afgeschermd codeblok en drukt voorspelbaar af in PDF-exports, zonder onhandige regelafbrekingen midden in een trefwoord.

Veelvoorkomende toepassingen

SQL-opmaak duikt op in analytics-engineering, backend-ontwikkeling en operationeel werk wanneer een query moet worden gelezen door iemand die hem niet heeft geschreven.

• Analytics-engineering: een pre-commit-hook in een dbt-project die elk modelbestand herformatteert zodat PR-diffs beperkt blijven tot logische wijzigingen en geen witruimteverschillen.
• Databasebeheer: plak een eenregelige slow-query-loginvoer, formatteer hem en loop door de join-volgorde terwijl je de incidentretro schrijft.
• Documentatie: haal een query op uit een Looker-explore of Tableau-werkmap, formatteer hem voor een draaiboek en sluit hem in als kopieerbaar voorbeeld voor de on-call-rotatie.

Een uitgewerkt voorbeeld

Plak SELECT u.id,u.email,COUNT(o.id) FROM users u LEFT JOIN orders o ON o.user_id=u.id WHERE u.created_at > '2024-01-01' GROUP BY u.id,u.email ORDER BY u.id; in het invoerpaneel met dialect PostgreSQL, inspringing 2 spaties en trefwoordhoofdletters HOOFDLETTERS. De uitvoer plaatst SELECT, FROM, LEFT JOIN, WHERE, GROUP BY en ORDER BY elk op een eigen regel; elke kolom in de selectielijst en de group-by-lijst krijgt een eigen ingesprongen regel; en het ON-predikaat staat één inspring dieper dan het JOIN-trefwoord waarbij het hoort. Dezelfde query via het BigQuery-dialect geeft voor dit geval identieke uitvoer, maar zou backtick-geciteerde identificatoren behouden als die aanwezig waren.

FAQ

Welke SQL-dialecten worden ondersteund?

Het dialectkeuzemenu omvat Standaard SQL, MySQL, PostgreSQL, SQLite, MariaDB, Transact-SQL (SQL Server / Azure SQL), BigQuery, Snowflake en Redshift. De onderliggende sql-formatter-bibliotheek herkent ook DuckDB, Spark SQL, Hive, Trino, Db2, N1QL, PL/SQL, ClickHouse, TiDB en SingleStoreDB — het dichtstbijzijnde dialect kiezen levert zinvolle uitvoer, zelfs als het exacte doel niet in de lijst staat. Identificatoren, stringliterals en dialectspecifieke operatoren (PostgreSQL @>, BigQuery SAFE.-prefixen) worden ongewijzigd doorgegeven.

Valideert dit mijn SQL?

Nee. De formatter is een lexicale herschrijver, geen parser. Hij tokeniseert de invoer, past layoutregels toe en geeft het resultaat terug; hij controleert niet of de query semantisch geldig is, of de genoemde tabellen bestaan of dat de syntaxis geldig is in het gekozen dialect. Voer de opgemaakte uitvoer door de daadwerkelijke database (of een SQL-linter zoals SQLFluff) voor een echte correctheidscontrole.

Waarom worden mijn trefwoorden omgezet naar hoofdletters?

De trefwoordhoofdletterkiezer staat standaard op HOOFDLETTERS, de conventie in de meeste gepubliceerde SQL-stijlgidsen (dbt Labs, Mode, GitLab). Schakel over naar kleine letters als jouw team select / from in kleine letters schrijft, of naar Behouden als je wilt dat de uitvoer de hoofdlettering behoudt die je hebt getypt. Identificatoren worden nooit aangeraakt — alleen de herkende trefwoordenset wordt herschreven.

Wordt mijn query ergens geüpload?

Nee. De meegeleverde sql-formatter-bibliotheek draait in je browser, de opmaak vindt lokaal op je computer plaats en de querytekst gaat de verbinding nooit over. De enige uitgaande verzoeken die deze pagina doet, zijn dezelfde gedeelde analyse- en advertentieverzoeken die elke pagina op tools.ultim8soft.com doet; de SQL-tekst zelf maakt geen deel uit van beide.

Pretty-printed SQL stopt de stijldiscussie zodra een formatter hem afhandelt. De tool draait volledig in je browser, de query verlaat de pagina nooit, en dezelfde dialectbewuste tokenizer die het sql-formatter npm-pakket aandrijft, voert de herschrijving uit.