SQL formatter/beautifier

SQL formatter/beautifier er et gratis værktøj, der gør SQL-kode mere læsbar og giver den en ensartet struktur.

Hvad ændrer SQL-formatering?

SQL-formatering ændrer en forespørgsels opbygning, så det bliver lettere at følge dens klausuler, udtryk og indlejrede strukturer. Det indebærer typisk linjeskift og indrykninger omkring elementer som SELECT-lister, JOIN-klausuler, WHERE-betingelser, underforespørgsler og CASE-udtryk.

Formatering bør ikke ændre forespørgslens tilsigtede resultat. SQL-dialekter er dog forskellige, og formatering alene kan ikke bevise, at en sætning har bevaret sin betydning. Gennemgå den genererede SQL, før du kører den på produktionsdata, især hvis den bruger leverandørspecifikke operatorer, procedureudvidelser eller usædvanlige regler for anførselstegn.

Et formateringsværktøj er nyttigt, når du læser forespørgsler fra andre, gennemgår genereret SQL, fejlsøger en lang sætning eller forbereder kode til en pull request. En ensartet struktur gør det også lettere at sammenligne ændringer, fordi uvedkommende forskelle i mellemrum begrænses.

Hvordan formaterer jeg SQL?

Indsæt eller skriv sætningen i feltet SQL, og indsend den for at få den formaterede version i Formateret SQL. Inputtet sendes til serveren via HTTPS, hvor det behandles uden at blive gemt.

1. Kopiér hele sætningen, herunder eventuelle common table expressions, som skal bevares, og kontrollér kommentarer samt et eventuelt afsluttende semikolon i resultatet.
2. Indsæt den i feltet SQL. Undgå om muligt kun at formatere isolerede dele.
3. Læs resultatet i Formateret SQL, og vær særligt opmærksom på indlejrede udtryk og dialektspecifik syntaks.
4. Kør den formaterede sætning i et egnet udviklings- eller stagingmiljø, før du tager den i brug.

Ved arbejde med følsomme databaser bør du kontrollere organisationens retningslinjer, før du sender forespørgselstekst til et serverbaseret værktøj. Fjern adgangskoder, adgangstokens, personoplysninger og fortrolige literalværdier, hvis de ikke er nødvendige for at forstå forespørgslen.

Hvordan læser jeg den formaterede SQL?

Følg indrykningerne og grænserne mellem klausulerne, når du læser resultatet. Betragt ikke det nye layout som bevis på, at sætningen er gyldig. SELECT, FROM, WHERE, GROUP BY og ORDER BY på øverste niveau er normalt lettere at skelne fra hinanden, når hver logisk del har sin egen linje eller sit eget indrykningsniveau.

• Indrykkede underforespørgsler viser, hvor et indre resultat bruges af en ydre sætning.
• Justerede betingelser gør det lettere at kontrollere prioriteten mellem AND og OR. AND har som standard højere prioritet end OR, mens parenteser fortsat bestemmer den logiske gruppering.
• Adskilte JOIN-klausuler gør det tydeligere, hvilken ON-betingelse der hører til hver tabel.
• Udfoldede SELECT-lister gør det lettere at opdage manglende kommaer, dublerede kolonner og tvetydige aliaser.
• Tydelige CASE-grene hjælper ved kontrollen af, om nøgleordene WHEN, THEN, ELSE og END passer sammen.

Strenge i anførselstegn, tal, tegnsætning og kommentarer har betydning i SQL. Kontrollér dem derfor i stedet for at antage, at de kun påvirker visningen. Tegn med accenter og ikke-latinske tegn kan være gyldige i streng-literals og citerede identifikatorer, afhængigt af databasen og dens tegnkodning.

Små eksempler på formatering

Se på dette kompakte input.

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

En læsbar, formateret version kan se sådan ud.

Output: SELECT id, name

FROM customers

WHERE active = 1

ORDER BY name;

Indrykning gør en endnu større forskel i en forespørgsel med et join.

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

Et læsbart output kan placere SELECT, FROM, JOIN, ON og WHERE på hver sin linje og samtidig bevare sammenligningen o.total > 100. Den præcise brug af store og små bogstaver, mellemrum og linjeskift afhænger af formateringsreglerne. Se derfor eksemplerne som mulige layouts, ikke som en garanteret kodestandard.

Kan formatering finde fejl i SQL?

Nej. At gøre SQL mere læsbar er ikke det samme som at validere den med en databaseparser. Værktøjets angivne resultat er formateret SQL, så det bør ikke betragtes som en syntakskontrol, skemakontrol eller eksekveringsplanlægger.

Et tydeligere layout kan alligevel afsløre sandsynlige fejl under gennemgangen. Det kan for eksempel være et manglende komma i en SELECT-liste, parenteser uden en tilsvarende start eller afslutning, en streng uden afsluttende anførselstegn, et JOIN uden den tilsigtede betingelse eller et forkert grupperet AND- eller OR-udtryk. Det kan også gøre det lettere at opdage et reserveret ord, der bruges som identifikator uden anførselstegn.

Nogle problemer kan ikke fastslås uden måldatabasen. En sætning, som PostgreSQL accepterer, kan kræve ændringer til Microsoft SQL Server, MySQL, Oracle Database eller SQLite. Manglende tabeller, ukendte kolonner, inkompatible datatyper og fejl i tilladelser kræver som regel databaseplatformen eller et dialektbevidst udviklingsværktøj for at kunne diagnosticeres.

Hvornår er SQL-formatering ikke umagen værd?

Formatering er som regel overflødig, hvis SQL-koden allerede er formateret ensartet eller kun skal behandles af en maskine. Omformatering af genererede forespørgsler kan skabe støjende ændringer i versionsstyringen uden at forbedre den generator, der har produceret dem.

Det kan også være det forkerte skridt i disse situationer:

• En migreringsfil er signeret, forsynet med en kontrolsum eller på anden måde sammenlignet byte for byte.
• En minificeret eller kompakt forespørgsel er indlejret i en størrelsesfølsom artefakt, og ingen behøver at gennemgå den.
• Den aktuelle opgave handler om validering, analyse af eksekveringsplaner eller optimering af ydeevnen frem for læsbarhed.
• Forespørgslen indeholder fortrolige værdier, som organisationens retningslinjer ikke tillader at sende til en serverbaseret tjeneste.

Til ensartet formatering af et helt repository kan et dialektbevidst kommandolinjeværktøj være bedre egnet, fordi dets konfiguration kan gemmes sammen med koden. Ved strukturerede API-payloads, som indeholder SQL, kan JSON validator & forskønner hjælpe med at gennemgå den omgivende JSON, mens selve SQL-koden stadig kræver SQL-specifik behandling.

Ofte stillede spørgsmål

Ændrer formatering, hvordan NULL fungerer?

Mellemrum og indrykninger ændrer ikke SQL's logik med tre sandhedsværdier eller den måde, NULL fungerer på. Kontrollér alligevel udtryk som column = NULL, der normalt skal skrives med IS NULL, da et formateringsværktøj ikke retter denne semantiske fejl.

Kan jeg formatere flere SQL-sætninger på én gang?

Det er ikke dokumenteret, at flere SQL-sætninger kan formateres på én gang. Formatér hver sætning separat.

Kan jeg roligt lade kommentarer blive i inputtet?

Kommentarer kan indeholde sagsreferencer, interne værtsnavne, kundeoplysninger eller driftsnoter, selv når den eksekverbare SQL ikke indeholder følsomme literalværdier. Gennemgå både linjekommentarer og blokkommentarer, før du sender teksten til serveren.

Skal SQL-nøgleord skrives med store eller små bogstaver?

Begge skrivemåder kan normalt bruges, fordi mange databaseplatforme behandler nøgleord uden anførselstegn uden at skelne mellem store og små bogstaver. Følg den konvention, der bruges i repositoriet, og vær forsigtig med citerede identifikatorer, da nogle databaser bevarer eller skelner mellem deres brug af store og små bogstaver.

Hvad skal jeg kontrollere, før jeg kører den formaterede forespørgsel?

Bekræft måldatabasens SQL-dialekt, gennemgå WHERE- og JOIN-betingelserne, og kontrollér transaktionsgrænserne for UPDATE, DELETE og sætninger, der ændrer skemaet. Kør risikable forespørgsler i en udviklings- eller stagingdatabase først, helst med repræsentative data og passende sikkerhedskopier.