SQL-stijlgids: best practices voor het formatteren

Een SQL-stijlgids is een set afspraken die query’s leesbaar maken en de diffs van een team consistent houden. SQL zelf trekt zich daar niets van aan: trefwoorden zijn hoofdletterongevoelig en witruimte wordt genegeerd, dus SELECT, select en SeLeCt draaien allemaal hetzelfde, en een oneliner van 200 tekens geeft precies dezelfde rijen terug als diezelfde query verspreid over twintig ingesprongen regels. Stijl gaat dus puur over de mensen die de query later lezen.

Heb je nu meteen een nette query nodig? Plak hem dan in de SQL Formatter, kies je dialect en kopieer het resultaat. Maar pas als je de regels achter die uitvoer begrijpt, kun je een teamstandaard vastleggen in plaats van er bij elke pull request opnieuw over te bakkeleien. Deze gids loopt door de keuzes die ertoe doen: hoofdletters van trefwoorden, inspringing en regelafbrekingen, naamgeving, dialectspecifieke eigenaardigheden, en hoe je het hele proces automatiseert.

Omdat SQL witruimte en hoofdletters negeert, dwingt de database geen van deze regels af; ze bestaan voor de mensen die de query lezen, reviewen en onderhouden. Dat verklaart twee dingen die in deze gids steeds terugkomen. Er is zelden één “juist” antwoord — de meeste beslissingen draaien om het kiezen van een redelijke afspraak en die overal toepassen, en ik ben eerlijk over waar de echte afwegingen liggen. En omdat het afspraken zijn en geen vereisten, leveren ze alleen iets op als je ze consistent toepast. Vandaar de conclusie onder elke sectie: beslis één keer en laat een tool het afdwingen.

Waarom SQL formatteren ertoe doet

Het duidelijkste argument voor formatteren zie je tijdens code review. Een ORM of een buildstap produceert query’s vaak als één ononderbroken regel:

select u.id,u.name,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.active=true group by u.id,u.name order by orders desc

Niemand kan dat reviewen. Geformatteerd is de structuur meteen duidelijk en is de diff regel voor regel te reviewen:

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Bij debuggen geldt hetzelfde. Als je een query van één regel uit een slow-query-log kopieert met drie joins en een verknoopte WHERE, maakt eerst formatteren van “waar zit de bug” een scan van dertig seconden. De foute predicaat staat op een eigen regel, de joins liggen op elkaar gestapeld, en een per ongeluk ontstaan Cartesisch product of een vergeten filter wordt ineens zichtbaar in plaats van verstopt in een muur van tekst. Dezelfde truc helpt als je SQL leest die een ander systeem heeft gegenereerd — query builders en rapportagetools staan erom bekend dat ze correcte maar onleesbare uitvoer produceren.

Consistentie is de stillere winst, en op termijn de meest waardevolle. Als iedereen op dezelfde manier formatteert, laten diffs alleen zien wat er werkelijk veranderd is — een nieuwe kolom, een aangepast filter — in plaats van ruis doordat de spatievoorkeur van de één botst met die van de ander. De aandacht van een reviewer is eindig; die besteden aan opnieuw uitgelijnde witruimte is verspilling. Consistent formatteren maakt ook het inwerken makkelijker: een nieuwe collega leest query’s die er allemaal hetzelfde uitzien, leert de vorm van het team één keer, en past die overal toe. Niets hiervan vereist dat iemand met de hand formatteert, en dat is het thema van de laatste sectie — jij bepaalt de regels, een tool past ze toe.

Eén invariant ligt hieronder, en die komt door de hele gids terug, dus benoem ik hem hier ronduit: formatteren verandert alleen witruimte, regelafbrekingen, hoofdletters van trefwoorden en commentaar. Het verandert nooit de logica van de query of de resultaten. Een geformatteerde query is dezelfde query. Daarom kun je de rommelige versie hierboven veilig door de SQL Formatter halen zonder je zorgen te maken over wat hij teruggeeft.

Hoofdletters van trefwoorden — UPPERCASE vs lowercase

De oudste discussie in elke SQL-stijlgids is of gereserveerde trefwoorden in UPPERCASE of lowercase moeten staan. Beide zijn geldig, want SQL is hoofdletterongevoelig voor trefwoorden. De onenigheid gaat over leesbaarheid, en het loont om beide kanten te begrijpen voordat je kiest.

Het argument voor hoofdletters in trefwoorden

Het traditionele argument is visueel contrast. SELECT, FROM, WHERE, JOIN en GROUP BY in hoofdletters laten de trefwoorden eruit springen tussen de tabel- en kolomnamen in kleine letters, zodat je de vorm van een query — de clausules, de structuur — kunt scannen zonder afhankelijk te zijn van een editor die ze inkleurt.

Dat telt zwaarder dan het klinkt, want SQL komt op veel plekken zonder syntaxiskleuring langs: logbestanden, beschrijvingen van pull requests, een platte diff, een Slack-bericht, een stacktrace. Daar zijn trefwoorden in hoofdletters het enige wat de structuur leesbaar houdt. Haal de kleuring weg en select id from users where active is een brij van woorden in kleine letters, terwijl SELECT id FROM users WHERE active nog in één oogopslag als query leest. Je vindt deze afspraak terug in de meeste oudere stijlgidsen, in databasedocumentatie en in vrijwel elk SQL-leerboek, en dat verklaart ook waarom veel ontwikkelaars trefwoorden in hoofdletters vertrouwder vinden, zelfs als hun editor ze toch zou inkleuren.

Het argument voor kleine letters in trefwoorden

Het moderne tegenargument is dat syntaxiskleuring het contrastprobleem heeft opgelost. Elke editor en IDE kleurt trefwoorden apart in, dus ze in hoofdletters zetten is overbodig — en voor sommige lezers leest alles in hoofdletters als geschreeuw. Het typt ook iets sneller zonder dat je voor elk trefwoord naar shift hoeft te reiken.

De stijl met kleine letters heeft echte momentum in de wereld van analytics engineering. De dbt-community en diverse veelgeciteerde teamstijlgidsen kiezen standaard voor trefwoorden in kleine letters, met als redenering dat de kleuring het visuele gewicht draagt en kleine letters de query rustiger leesbaar houden. Er speelt ook een subtieler punt in hun voordeel: trefwoorden in kleine letters zitten op hetzelfde visuele niveau als je snake_case-tabel- en -kolomnamen, zodat de hele query als één consistent stuk tekst leest in plaats van als twee registers, schreeuwende trefwoorden naast stille identifiers. Of dat een voordeel of een nadeel is, is precies het soort discussie waar teams het oneens over worden, en dat brengt ons bij het enige oordeel dat werkelijk standhoudt.

Het oordeel — consistentie wint van de keuze

Hier komt het deel dat er echt toe doet: welke je kiest is veel minder belangrijk dan er één kiezen en die afdwingen. Een codebase waar de helft van de query’s SELECT schreeuwt en de andere helft select fluistert, is de slechtste uitkomst, want de inconsistentie zelf wordt ruis. Gemengde hoofdletters binnen één query is nog erger.

De reden dat consistentie wint is mechanisch, niet esthetisch. Inconsistente hoofdletters laten diffs liegen: een reviewer ziet een regel “veranderen” die in werkelijkheid alleen iemand is die een trefwoord opnieuw formatteert, en de echte wijziging verschuilt zich in de ruis. Grep en zoeken worden ook minder betrouwbaar als hetzelfde trefwoord in drie schrijfwijzen verschijnt. Eén afgedwongen stijl haalt al die overhead weg ten koste van één beslissing. Beslis dus als team, leg het vast, en laat een tool het afdwingen in plaats van te leunen op discipline. De SQL Formatter heeft een Keywords-instelling met drie opties — UPPERCASE, lowercase en Preserve — zodat je een hele stapel historische query’s in één klik naar één stijl normaliseert. Dezelfde query, beide kanten op weergegeven:

-- UPPERCASE
SELECT id, email FROM users WHERE active = true ORDER BY created_at DESC;

-- lowercase
select id, email from users where active = true order by created_at desc;

Kies degene die jouw team verkiest. Het punt is dat al je query’s er bij passen.

Inspringing en regelafbrekingen

Hoofdletters bepalen hoe trefwoorden eruitzien. Inspringing en regelafbrekingen bepalen hoe de logica van de query op de pagina wordt afgebeeld, en daar zit het grootste deel van de leesbaarheid.

De “river”-stijl vs blokstijl

Simon Holywell’s bekende sqlstyle.guide maakte de “river”-stijl populair, waarbij trefwoorden rechts worden uitgelijnd zodat er een verticaal kanaal van witruimte door het midden van de query loopt:

SELECT id,
       email,
       created_at
  FROM users
 WHERE active = true
 ORDER BY created_at DESC;

De charme is dat SELECT, FROM en WHERE aan hun rechterkant uitlijnen en de kolomlijst netjes rechts van de river zit. De nadelen zijn echter praktisch. De uitlijning hangt af van de lengte van je langste trefwoord, dus een LEFT JOIN toevoegen kan je dwingen alles opnieuw in te springen; het is pijnlijk om met de hand te onderhouden; en het levert rommelige diffs op, want de lengte van één trefwoord veranderen verschuift de witruimte op aangrenzende regels.

De blokstijl (of links uitgelijnde stijl) begint elke hoofdclausule op een eigen regel aan de linkermarge en springt de inhoud van de clausule in:

SELECT
  id,
  email,
  created_at
FROM users
WHERE active = true
ORDER BY created_at DESC;

Dit is de gangbare standaard en de stijl die de meeste tools produceren, juist omdat hij stabiel is: een clausule toevoegen herschikt nooit de regels erboven, dus diffs blijven klein en de opmaak overleeft automatisch formatteren. De river-stijl optimaliseert voor hoe een afgeronde query er op zichzelf uitziet; de blokstijl optimaliseert voor hoe query’s in de loop van de tijd veranderen en hoe ze reviewen in versiebeheer. Voor alles wat in een repository leeft en bewerkt wordt, is de blokstijl de veiligere keuze, en die gaat de rest van deze gids ervan uit.

Hoeveel spaties — 2 vs 4 vs tabs

Zodra je inspringt, moet je beslissen hoe ver. De drie gangbare antwoorden hebben elk hun redenering:

• 2 spaties — de meest voorkomende standaard. Het houdt diffs compact en voorkomt dat geneste query’s van de rechterrand van het scherm aflopen.
• 4 spaties — geeft elk inspringniveau meer visuele scheiding, wat helpt bij query’s met diepe subquery’s of veel CTE-niveaus.
• Tabs — laten elke ontwikkelaar zijn eigen weergavebreedte kiezen zonder het bestand te wijzigen.

Er is hier geen universeel juist antwoord, en precies daarom biedt de SQL Formatter een Indent-instelling met alle drie (2 spaces, 4 spaces, Tab). Kies er één en pas hem overal toe.

Waar je regels afbreekt

Inspringbreedte is het makkelijke deel. De beslissing met meer impact is waar je regelafbrekingen invoegt:

• SELECT-kolommen — één kolom per regel voor alles wat niet triviaal is, zodat een kolom toevoegen of verwijderen precies één regel in de diff raakt. Heel korte query’s mogen op één regel blijven.
• FROM en JOIN — begin elke join op een eigen regel, met de ON-voorwaarde er achteraan of eronder ingesprongen. Zo blijft de join-graaf leesbaar.
• WHERE — zet elke AND / OR op een eigen regel zodat de booleaanse logica van boven naar beneden leest. Bij gemengde AND/OR-voorwaarden zet je haakjes en springt je de groepen in, zodat de voorrang expliciet is in plaats van iets wat de lezer zelf moet uitpuzzelen.

Dit zijn richtlijnen, geen wetten. Een triviale SELECT id FROM users WHERE id = 1 heeft geen vijf regels nodig, en hem daar toch op forceren schaadt de leesbaarheid in plaats van te helpen. De afweging luidt ongeveer: breek af als de query meer dan een of twee kolommen heeft, meer dan één tabel, of meer dan één voorwaarde. Daaronder is één regel duidelijker; daarboven breek je rigoureus af. Een goede formatter codeert een verstandige drempel voor je, maar het is de moeite waard om het principe te begrijpen, zodat de uitvoer je nooit verrast.

Toegepast op de rommelige oneliner van eerder leveren die regels een opmaak op waarin elke clausule en elke join in één oogopslag zichtbaar is:

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Komma’s vooraan vs achteraan

Een kleinere maar hardnekkige vraag: waar komt de komma in een kolomlijst over meerdere regels?

-- Leading commas
SELECT
    id
  , email
  , created_at
FROM users;

-- Trailing commas
SELECT
    id,
    email,
    created_at
FROM users;

Komma’s vooraan hebben een echt voordeel: een kolom toevoegen of verwijderen verandert één regel, en een ontbrekende komma is makkelijk te zien omdat de betreffende regel eruit springt. Komma’s achteraan lezen natuurlijker en zijn in de praktijk veel gangbaarder. Beide zijn prima — kies er één en laat de formatter het toepassen, zodat niemand er ooit nog over hoeft na te denken.

Naamgevingsconventies voor tabellen en kolommen

Formatteren regelt de witruimte; naamgeving regelt de identifiers zelf, en een stijlgids is onvolledig zonder.

De feitelijke standaard voor SQL-identifiers is snake_case — volledig in kleine letters, woorden gescheiden door underscores: user_id, created_at, order_items. Die status verdient het om een concrete reden, niet uit gewoonte: snake_case-identifiers hoeven nooit te worden gequoot en gedragen zich consistent over dialecten heen, terwijl camelCase (gangbaar in applicatiecode) botst met hoe databases hoofdletters omzetten, iets waar we zo op terugkomen.

Het is goed om expliciet te zijn over waarom dit verschilt van applicatiecode. In de meeste programmeertalen bepaalt de omringende code de identifiers, en is camelCase of PascalCase de norm. SQL-identifiers daarentegen worden geïnterpreteerd door de eigen hoofdletteromzettingsregels van de database, en juist die regels maken namen met gemengde hoofdletters kwetsbaar. snake_case ontwijkt de hele kwestie: er is geen hoofdletter om om te zetten, geen reden om te quoten, en niets wat zich van engine tot engine anders gedraagt.

Nog een paar afspraken die in vrijwel elke SQL-stijlgids opduiken:

• Enkelvoudige vs meervoudige tabelnamen is een echte tweedeling. users (meervoud, “de tabel bevat users”) en user (enkelvoud, “elke rij is een user”) hebben allebei voorstanders. Net als bij hoofdletters telt de keuze minder dan hem consistent op elke tabel toepassen.
• Vermijd gereserveerde woorden als identifiers. Een kolom order, user of table noemen dwingt je om hem overal te quoten en nodigt verwarrende fouten uit. Grijp in plaats daarvan naar order_id of account.
• Houd de naamgeving van sleutels consistent. Een primaire sleutel met de naam id en vreemde sleutels met de naam <referenced_table>_id (zoals user_id) maken joins voorspelbaar en zelfdocumenterend.

Er is één valkuil die het waard is om expliciet te benoemen, want hij bijt teams die databasekolommen net zo benoemen als hun applicatievariabelen. In PostgreSQL wordt een niet-gequote identifier omgezet naar kleine letters, dus SELECT userId FROM t zoekt eigenlijk naar een kolom met de naam userid. Op het moment dat je hem quoot — "userId" — bewaart de database de hoofdletters en behandelt "userId" en userid als twee verschillende kolommen:

-- Creates a column whose real name is lowercase "userid"
CREATE TABLE t (userId integer);

-- Both of these work — the name was folded to lowercase
SELECT userId FROM t;
SELECT userid FROM t;

-- This fails: "column \"userId\" does not exist"
-- The quotes force an exact, case-sensitive match
SELECT "userId" FROM t;

Let op: verschillende databases zetten hoofdletters in verschillende richtingen om — Oracle zet niet-gequote identifiers om naar hoofdletters, diverse andere naar kleine letters — dus gequote identifiers met gemengde hoofdletters zijn niet eens porteerbaar. De schone uitweg is om gequote identifiers met gemengde hoofdletters volledig te vermijden en bij snake_case te blijven, wat het hele probleem omzeilt en je schema in elk dialect leesbaar houdt.

Voor een diepere vergelijking van camelCase, snake_case en kebab-case — inclusief wanneer elk de juiste keuze is over code en data heen — zie de naamgevingsconventies-gids.

Formatteren over SQL-dialecten heen

Alles tot nu toe is grotendeels dialectonafhankelijk — hoofdletters, inspringing, regelafbrekingen en naamgeving gelden ongeacht welke database je gebruikt. Maar “formatteer deze SQL” loopt tegen een muur op zodra je query syntaxis gebruikt die specifiek is voor één database, want een generieke parser die die syntaxis niet herkent, verminkt hem: hij kan een token op de verkeerde plek splitsen, een operator verkeerd lezen, of een quote-teken als stringscheider behandelen en de halve query inslikken. Hier verdient dialectbewust formatteren zijn nut, en daarom vraagt de formatter je eerst een database te kiezen in plaats van te gokken. De verschillen hieronder zijn die je in alledaagse query’s het vaakst tegenkomt.

Bewerking	PostgreSQL	MySQL / MariaDB	SQL Server (T-SQL)	Oracle	Standard SQL
Tekenreeksen samenvoegen	|| of CONCAT()	CONCAT()	+ of CONCAT()	|| of CONCAT()	||
NULL-fallback	COALESCE()	COALESCE() / IFNULL()	COALESCE() / ISNULL()	COALESCE() / NVL()	COALESCE()
Rijen beperken	LIMIT	LIMIT	TOP / OFFSET … FETCH	FETCH FIRST	FETCH FIRST
Identifiers quoten	dubbele aanhalingstekens ("…")	backticks	vierkante haken ([…])	dubbele aanhalingstekens ("…")	dubbele aanhalingstekens ("…")

String-samenvoeging en NULL-afhandeling

Twee van de meest voorkomende alledaagse bewerkingen worden in verschillende dialecten anders geschreven.

String-samenvoeging:

-- PostgreSQL, Oracle, SQLite (standard operator)
SELECT first_name || ' ' || last_name AS full_name FROM users;

-- SQL Server (T-SQL uses +)
SELECT first_name + ' ' + last_name AS full_name FROM users;

-- Portable across dialects
SELECT CONCAT(first_name, ' ', last_name) AS full_name FROM users;

NULL-fallbacks:

-- Standard SQL (works everywhere)
SELECT COALESCE(nickname, name) AS display_name FROM users;

-- SQL Server only
SELECT ISNULL(nickname, name) AS display_name FROM users;

-- MySQL / MariaDB only
SELECT IFNULL(nickname, name) AS display_name FROM users;

Een formatter die op het verkeerde dialect staat, begrijpt ISNULL of de ||-operator misschien niet en kan de omringende query verkeerd parseren.

Rijen beperken en identifiers quoten

Het beperken van het aantal resultaatrijen is een van de meest dialectafhankelijke stukken syntaxis:

-- PostgreSQL, MySQL, SQLite
SELECT id, name FROM users ORDER BY created_at DESC LIMIT 10;

-- SQL Server (T-SQL)
SELECT TOP 10 id, name FROM users ORDER BY created_at DESC;

-- Standard SQL / Oracle
SELECT id, name FROM users ORDER BY created_at DESC FETCH FIRST 10 ROWS ONLY;

Identifiers quoten splitst ook drie kanten op. Wanneer je een identifier moet quoten — meestal om een gereserveerd woord te gebruiken of hoofdletters te bewaren — hangt de scheider af van de database:

-- MySQL / MariaDB use backticks
SELECT `order`, `user` FROM `select`;

-- SQL Server (T-SQL) uses square brackets
SELECT [order], [user] FROM [select];

-- Standard SQL (PostgreSQL, Oracle, SQLite) uses double quotes
SELECT "order", "user" FROM "select";

Een formatter die denkt dat MySQL-backticks stringscheiders zijn, of dat T-SQL-brackets iets anders zijn, produceert kapotte uitvoer. De dialectinstelling is wat hem vertelt wat wat is. Dit is ook waarom een query tussen databases kopiëren-plakken zelden een schone wissel is: dezelfde logische intentie — twee strings samenvoegen, terugvallen op NULL, beperken tot tien rijen, een gereserveerd woord quoten — wordt over de dialecten heen op vier verschillende manieren geschreven, en alleen de parser die jouw database kent, kan het herformatteren zonder het te corrumperen.

Waarom dialectbewust formatteren ertoe doet

Dit is precies waarom de SQL Formatter wordt geleverd met negen dialecten — PostgreSQL, MySQL, SQL Server (T-SQL), BigQuery, Snowflake, Oracle, SQLite, MariaDB en Standard SQL — in plaats van één generieke modus. De juiste kiezen betekent dat de parser PostgreSQL dollar-quoted strings en ::-casts, T-SQL bracketed identifiers en TOP, warehouse-specifieke functies in BigQuery en Snowflake, en de quoteregels hierboven correct afhandelt, in plaats van te gokken en het mis te hebben. Kies je echte database uit de dropdown voordat je formatteert, en de uitvoer komt correct en idiomatisch terug.

SQL-formatteren automatiseren

De regels lezen is één ding; niemand zou ze met de hand moeten toepassen. Het hele punt van een stijlgids is dat een machine hem afdwingt. Er zijn drie plekken om formatteren in te bouwen, afhankelijk van hoeveel wrijving je wilt wegnemen.

In je editor (formatteren bij opslaan)

De optie met de minste inspanning is om automatisch te formatteren elke keer dat je opslaat. VS Code heeft SQL-formatter-extensies die bij het opslaan draaien, en JetBrains DataGrip en de databasetools in andere IDE’s worden geleverd met een ingebouwde formatter die je aan een toetsaanslag of een opslaghook kunt koppelen. Eenmaal ingesteld zijn je query’s simpelweg nooit ongeformatteerd — hetzelfde model als Prettier voor JavaScript of gofmt voor Go. De adder onder het gras is dat editorinstellingen op de machine van elke ontwikkelaar staan, dus formatteren bij opslaan houdt jouw SQL netjes, maar garandeert op zichzelf niet dat de rest van het team dat ook doet. Daarvoor heb je de volgende laag nodig.

In CI met een linter

Om stijl over een heel team af te dwingen, verplaats je de controle naar continuous integration. Een SQL-linter zoals sqlfluff lint én fixt automatisch: je codeert je regels — dialect, hoofdletters van trefwoorden, inspringing, kommaplaatsing — in een .sqlfluff-configuratiebestand, draait sqlfluff lint om overtredingen te markeren en sqlfluff fix om ze te repareren, en laat CI elke pull request falen die afwijkt van de afgesproken stijl. Dit is hetzelfde idee als ESLint of Prettier die een frontend-repo bewaken: stijl is niet langer een reviewopmerking die iemand moet onthouden om te plaatsen, maar wordt een slagende of falende controle die de machine nooit vergeet. De beloning is dat stijldiscussies één keer plaatsvinden, wanneer je de config schrijft, in plaats van bij elke pull request.

Eenmalig online formatteren

Soms heb je gewoon één lelijke query en geen zin om iets te installeren — een fragment uit een log, het Slack-bericht van een collega, een query die je in documentatie plakt. Plak hem daarvoor in de SQL Formatter, kies het dialect, de hoofdletters en de inspringing, en kopieer het schone resultaat.

Het privacydetail telt hier, en het wordt makkelijk over het hoofd gezien. Veel online formatters sturen de tekst die je plakt naar een server om het werk te doen, wat betekent dat een kopie van je query — tabelnamen, kolomnamen, soms letterlijke waarden uit een productie-incident — je machine verlaat. De SQL Formatter draait volledig in je browser, dus je SQL wordt nergens geüpload. Daardoor is het veilig om query’s te formatteren die productieschema’s of bedrijfseigen logica raken, en dat is precies de situatie waarin je het schone formatteren het hardst wilt en je query het minst aan een derde partij wilt geven. Werk je in dezelfde workflow met andere formaten? Dan werkt de zusterversie JSON Formatter op dezelfde manier — dezelfde verwerking in de browser, dezelfde kopieerknop met één klik.

De drie aanpakken sluiten elkaar niet uit, en de beste opzet combineert ze meestal: formatteren bij opslaan voor de snelle inner loop terwijl je schrijft, een CI-linter als vangnet dat de teamstandaard afdwingt, en een online formatter voor de wegwerpfragmenten die je repo nooit raken. Welke je ook pakt, onthoud de invariant nog één laatste keer — geen van deze tools verandert wat je query doet. Ze herschikken witruimte, regelafbrekingen, hoofdletters en commentaar, en verder niets.

Veelgestelde vragen

Moeten SQL-trefwoorden in hoofdletters of kleine letters?

Beide zijn geldig, want SQL-trefwoorden zijn hoofdletterongevoelig. UPPERCASE laat trefwoorden opvallen in omgevingen zonder syntaxiskleuring, zoals logs en diffs; lowercase typt makkelijker en past bij moderne editors die trefwoorden al inkleuren. Wat echt telt is dat het hele team er één kiest en een formatter het afdwingt — gemengde hoofdletters is de slechtste keuze.

Wat is de beste inspringing voor SQL?

Twee spaties is de meest voorkomende standaard en houdt diffs compact; vier spaties maakt diep geneste query’s makkelijker leesbaar; tabs laten elke ontwikkelaar zijn eigen weergavebreedte kiezen. Er is geen enkel juist antwoord — kies er één en pas hem consistent toe binnen je team. De meeste SQL-formatters, waaronder deze, ondersteunen alle drie de opties.

Hoe formatteer ik SQL automatisch?

Er zijn drie manieren om SQL automatisch te formatteren: formatteren bij opslaan in je editor (VS Code of DataGrip), een linter in CI zoals sqlfluff die de stijl automatisch fixt, of een online SQL-formatter voor eenmalig plakken. De online route is het snelst omdat er geen installatie nodig is — gewoon plakken, je dialect kiezen en het resultaat kopiëren.

Moet ik komma’s vooraan of achteraan gebruiken in SQL?

Komma’s vooraan (komma aan het begin van elke regel) geven schonere diffs bij het toevoegen of verwijderen van kolommen en maken een ontbrekende komma makkelijk te zien; komma’s achteraan (komma aan het eind) lezen natuurlijker en zijn gangbaarder. Beide zijn acceptabel in elke SQL-stijlgids — de sleutel is er één kiezen en een formatter het automatisch laten toepassen.

Verandert het formatteren van SQL hoe de query draait?

Nee. SQL formatteren verandert alleen witruimte, regelafbrekingen, hoofdletters van trefwoorden en commentaar — het verandert nooit de logica van de query. Een geformatteerde query geeft precies dezelfde resultaten terug als het origineel, en daarom is het volkomen veilig om zelfs productiequery’s te verfraaien voordat je ze reviewt of draait.

Welke naamgevingsconventie moet ik gebruiken voor SQL-tabellen en -kolommen?

snake_case — volledig in kleine letters met underscores — is de feitelijke standaard voor SQL-tabel- en -kolomnamen omdat het quoten voorkomt en veilig blijft over dialecten heen. Houd primaire sleutels (id) en vreemde sleutels (user_id) consistent benoemd, en vermijd gereserveerde woorden zoals order of user als identifiers om quote-ellende te voorkomen.

Hoe formatteer ik SQL voor een specifiek dialect zoals PostgreSQL of T-SQL?

Selecteer eerst het bijbehorende dialect in de formatter. De PostgreSQL-modus handelt ::-casts en dollar-quoted strings correct af; de SQL Server (T-SQL)-modus begrijpt bracketed [identifiers] en TOP. Het verkeerde dialect kiezen laat een generieke parser dialectspecifieke syntaxis verminken, dus stel hem altijd in op je echte database voordat je formatteert.

Bestaat er een standaard SQL-stijlgids?

Er is geen officiële standaard, maar er bestaan verschillende veelgenoemde gidsen: Simon Holywell’s sqlstyle.guide en de openbare stijlgidsen van teams zoals Mozilla en de dbt-community. Hun gedeelde consensus — consistente inspringing, snake_case-identifiers en een regelafbreking vóór elke hoofdclausule — is wat deze gids codificeert, en een formatter kan het voor je afdwingen.