SQL Formatterer & Validator - Formater SQL-spørringer på nettet gratis
Gratis SQL-formatterer og validator. Formater SQL automatisk med riktig innrykk og stor/liten bokstav. Sjekk syntaksfeil umiddelbart. Fungerer med MySQL, PostgreSQL, SQL Server, Oracle.
SQL Formatterer & Validator
Formater og valider SQL-spørringer med automatisk innrykk, nøkkelordkapitalisering og syntaksfeildeteksjon.
Dokumentasjon
Hvorfor SQL-formatering er viktig
Har du noen gang arvet et databaseprosjekt der SQL-en ser ut som om noen har skrevet den med bind for øynene? Du er ikke alene. Dårlig formatert SQL er en av de vanligste kildene til feil og bortkastet tid i databaseutvikling.
Denne SQL-formattereren og validatoren hjelper deg med å rydde opp i rotete spørringer automatisk. Lim inn SQL-en din, og den setter umiddelbart inn riktig innrykk, setter store bokstaver på nøkkelord og sjekker for syntaksfeil—alt i nettleseren din uten å sende data til noen server. Det som vanligvis tar 10-15 minutter med manuell formatering, skjer på sekunder.
Etter min erfaring med databaseteam er den største tidsbesparelsen ikke bare formateringen—det er å oppdage feil før de når produksjon. En feilplassert parentes eller en uavsluttet anførselstegn kan kaste bort timer med feilsøking. Dette verktøyet fanger opp slike problemer umiddelbart, før du kjører noe mot databasen din.
Hvordan bruke SQL-formatteringen
Grensesnittet er bevisst minimalt—bare lim inn og kjør:
- Lim inn SQL-en i inndatabolksen (eller skriv den direkte hvis du skriver fra bunnen av)
- Se den formateres automatisk mens du skriver—ingen knapper å klikke, ingen innstillinger å konfigurere
- Gjennomgå valideringsfeil hvis noen vises under den formaterte utgangen
- Kopier den formaterte SQL-en med ett klikk for å bruke i din IDE, dokumentasjon eller databaseverktøy
Fungerer på alle enheter med en nettleser. Formateringen skjer helt på klientsiden, så dine spørringer forlater aldri maskinen din—viktig når du arbeider med produksjonsdatabasestrukturer eller sensitive skjemaer.
Hva SQL-formattereren gjør
Nøkkelordkapitalisering
Alle SQL-nøkkelord blir automatisk kapitalisert—SELECT, FROM, WHERE, JOIN, og så videre. Dette følger konvensjonen som brukes av de fleste databaseteam og gjør nøkkelord visuelt distinkte fra dine tabell- og kolonnenavn. Når du ser gjennom en kompleks spørring, hjelper denne visuelle separeringen deg med å identifisere spørringens struktur med ett blikk.
Smart innrykk
Formattereren strukturerer din SQL basert på logisk hierarki i stedet for bare å legge til tilfeldige linjeskift. Hovedklausuler som SELECT og FROM starter ved venstre margin. JOIN-klausuler rykkes inn under FROM for å vise at de er en del av tabellvalget. Underspørringer får ytterligere innrykningsnivåer, noe som gjør nestet logikk tydelig.
Her er hva som skjer i praksis: når du har en spørring med flere joins og underspørringer, lar riktig innrykk deg se spørringens struktur uten å lese hvert ord. Du kan umiddelbart se hvor en join slutter og en annen begynner, eller hvor en underspørring blir brukt i din SELECT-liste.
Logiske linjeskift
Linjeskift vises der de forbedrer lesbarhet, ikke overalt. Hver hovedklausul får sin egen linje. Elementer i kommaseparerte lister (som kolonnenavn i SELECT) får hver sin linje med riktig innrykk. Underspørringer er visuelt atskilt. CASE-setninger brytes ved WHEN, THEN, og ELSE for klarhet.
Mellomrommet følger SQL Style Guide-konvensjonene som brukes på tvers av bransjen, noe som betyr at din formaterte SQL vil se kjent ut for andre utviklere.
SQL-validering: Hva som blir sjekket
Validatoren fanger opp feil som vanligvis slipper gjennom når du skriver SQL raskt. Den vil ikke erstatte databasens spørringsanalyse, men den fanger opp vanlige feil før du i det hele tatt kjører spørringen.
Strukturelle feil
Ubalanserte parenteser er overraskende vanlig i komplekse spørringer med nestede underspørringer. Validatoren teller åpne og lukkede parenteser for å umiddelbart flagge avvik. Jeg har sett produksjonstilfeller forårsaket av en enkelt manglende parentes i en 200-linjes spørring—dette fanger dem tidlig.
Uavsluttede strenglitteraler skjer når du glemmer avsluttende anførselstegn på en strengverdi. Databasen din vil umiddelbart avvise disse, men å fange dem her sparer en rundtur.
Klausul-rekkefølgefeil blir flagget når klausuler dukker opp i feil sekvens. For eksempel hvis du setter HAVING før GROUP BY, eller WHERE etter GROUP BY, varsler validatoren deg. Dette følger SQL-standardens syntaksregler definert i ISO/IEC 9075 SQL-standarden.
Logiske feil
JOIN-klausuler uten ON-betingelser skaper utilsiktede krysssammenslåinger som returnerer langt flere rader enn tiltenkt. Et vanlig scenario: du legger til en tredje eller fjerde tabell i en spørring og glemmer ON-klausulen. Uten denne sjekken vil du kanskje ikke legge merke til før du ser tusenvis av dupliserte rader i resultatene.
HAVING uten GROUP BY er teknisk ugyldig SQL i de fleste databaser. HAVING-klausulen filtrerer grupperte resultater, så den krever en GROUP BY for å fungere. Validatoren fanger opp denne logiske uoverensstemmelsen.
Ufullstendige WHERE-betingelser skjer når du begynner å skrive en betingelse men ikke fullfører den—som WHERE status = uten noen verdi. Disse er lette å overse når du redigerer spørringer.
Hva den ikke vil fange opp
Denne validatoren fokuserer på syntaks og struktur, ikke databaseskjema. Den vil ikke vite om:
- Tabell- eller kolonnenavnene eksisterer i databasen din
- Du slår sammen kompatible datatyper
- Spørringen din vil prestere godt eller har optimaliseringsproblemer
- Du har tillatelse til å få tilgang til tabellene du spør
Tenk på den som en førstegangssjekk før du sender spørringen til den faktiske databasen.
Formateringsregler som brukes av dette verktøyet
Formatteren bruker konsistente regler basert på SQL-stilguiden som de fleste databaseteam følger.
Nøkkelord skrives med store bokstaver
Hver SQL-nøkkelord blir skrevet med store bokstaver: SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, DROP. Dette inkluderer klausuler (FROM, WHERE, GROUP BY, HAVING, ORDER BY), join-typer (JOIN, INNER JOIN, LEFT JOIN), operatorer (AND, OR, NOT, IN, BETWEEN, LIKE), og vanlige funksjoner (COUNT, SUM, AVG, CASE, WHEN).
Hvorfor store bokstaver? Det skaper visuell forskjell mellom SQL-språkelementene og dine databasespesifikke navn (tabeller, kolonner, aliaser). Når du scanner en spørring, fanger øyet umiddelbart opp strukturen.
To-stegs innrykk per nivå
Hovedklausuler som SELECT og FROM starter ved venstre margin. JOIN-klausuler rykkes inn to mellomrom under FROM for å vise at de er en del av tabellvalget. Underspørringer rykkes inn ytterligere to mellomrom for hvert nestingsnivå. Dette skaper et visuelt hierarki som matcher den logiske strukturen.
Kommaseparerte lister (kolonnenavn i SELECT, for eksempel) får hver sin linje med konsistent innrykk. Når du har 15 kolonner i SELECT-listen, gjør dette det enkelt å scanne og finne spesifikke kolonner.
Betingelser i WHERE-klausuler justeres vertikalt. Når du har flere AND- eller OR-betingelser, gjør justering den logiske strukturen umiddelbart tydelig.
Før og etter: Se forskjellen
Før formatering:
1select u.id, u.name, o.order_date from users u join orders o on u.id = o.user_id where o.status = "completed" group by u.id order by u.name;
2Etter formatering:
1SELECT
2 u.id,
3 u.name,
4 o.order_date
5FROM users u
6 JOIN orders o ON u.id = o.user_id
7WHERE
8 o.status = "completed"
9GROUP BY
10 u.id
11ORDER BY
12 u.name;
13Valideringsregler: Hva som blir flagget
Validatoren sjekker strukturell integritet og grunnleggende logisk konsistens. Her er hva den ser etter:
Strukturelle sjekk
Balanserte parenteser: Åpnings- og lukkeparenteser må stemme. Nestede underspørringer har ofte flere nivåer av parenteser, og feilberegning av disse er en av de vanligste SQL-feilene. Validatoren teller dem for deg.
Riktig lukkede strenger: Hver åpningssitat (enkelt eller dobbelt) trenger en lukking. Det høres opplagt ut, men når du skriver en kompleks spørring med flere strenglitteraler, er det lett å glemme en.
Riktig klausulrekkefølge: SQL har spesifikke rekkefølgekrav. SELECT kommer før FROM, som kommer før WHERE, som kommer før GROUP BY, som kommer før HAVING, som kommer før ORDER BY. Å sette dem i feil rekkefølge forårsaker umiddelbare syntaksfeil. Validatoren sjekker denne rekkefølgen basert på SQL-standarden.
Logiske konsistenssjekk
JOIN med ON-betingelse: Hver JOIN trenger en ON- eller USING-klausul for å spesifisere hvordan tabeller er relatert. Uten den får du en krysskobling—hver rad fra én tabell paret med hver rad fra en annen. Det er sjelden det du vil, og indikerer vanligvis en manglende ON-klausul.
Fullstendige WHERE-betingelser: En WHERE-klausul trenger fullstendige predikat. WHERE status = uten en verdi er ufullstendig og ugyldig. Validatoren flagger disse delvise betingelsene.
HAVING krever GROUP BY: HAVING-klausulen filtrerer grupperte resultater, så den gir bare mening når du har en GROUP BY. Bruk av HAVING uten GROUP BY er en logisk feil som de fleste databaser avviser.
GROUP BY aggregeringsregler: Når du bruker aggregatfunksjoner som COUNT() eller SUM(), må alle ikke-aggregerte kolonner i SELECT-listen vises i GROUP BY. Dette er et grunnleggende SQL-krav som validatoren sjekker.
Eksempel på vanlige feil som oppdages
Her er SQL med flere problemer som validatoren ville flagge:
1SELECT user_id, COUNT(*) FROM orders
2JOIN users
3WHERE status =
4GROUP BY
5HAVING count > 10;
6Oppdagede problemer:
JOIN usersmanglerON-betingelse (vil lage krysskobling)WHERE status =ufullstendig (ingen sammenligningsverdi)- Tom
GROUP BY-klausul (ingen kolonner spesifisert) HAVING count > 10refererer til udefinert kolonne
Når du skal bruke denne SQL-formatteringen
Under kodeanmeldelser
Har du noen gang prøvd å gjennomgå en 50-linjes SQL-spørring som er skrevet på én linje? Det er brutalt. Før du sender inn spørringer til kodeanmeldelse, kjør dem gjennom formatteringen. Dine anmeldere vil takke deg, og de vil faktisk kunne fokusere på logikk i stedet for å avkode strukturen.
Når du gjennomgår pull-forespørsler med databaseendringer, be bidragsytere om å formatere SQL-en først. Det gjør det mye enklere å oppdage logiske feil når strukturen er konsistent.
Feilsøking av produksjonsproblemer
Når du feilsøker en mislykket spørring i produksjon, hjelper riktig formatering deg med å se strukturen tydelig. Jeg har feilsøkt utallige spørringer der problemet ble åpenbart så snart SQL-en var riktig formatert—en manglende join-betingelse, en feil WHERE-klausul gruppering, eller en underspørring på feil plass.
Kopier spørringen fra loggene dine, lim den inn her, og du vil umiddelbart se om det er strukturelle problemer.
Arbeide med generert SQL
ORMs (Object-Relational Mappers) som Hibernate, Entity Framework eller SQLAlchemy genererer SQL automatisk. Noen ganger trenger du å se hva slags spørring de faktisk produserer. Den genererte SQL-en er vanligvis én lang linje uten formatering. Dette verktøyet gjør ORM-genererte spørringer lesbare slik at du kan forstå og optimalisere dem.
Undervise og lære SQL
Hvis du lærer SQL eller underviser i det, hjelper denne formatteringen deg med å forstå riktig spørringsstruktur. Når du limer inn en fungerende spørring og ser hvordan den formateres, lærer du konvensjonene. Når du limer inn en ødelagt spørring og ser valideringsfeilene, forstår du hvorfor den ikke fungerer.
Migrere mellom databasesystemer
Forskjellige databaser (PostgreSQL, MySQL, SQL Server) har litt forskjellige SQL-dialekter. Når du migrerer spørringer mellom systemer, hjelper riktig formatering deg med å oppdage dialektspesifikk syntaks som kanskje trenger justering. Formatteringen følger standard SQL-konvensjoner som fungerer på tvers av de fleste store databaser.
Alternativer til denne SQL-formattereren
Database-Spesifikke IDEer
Verktøy som DataGrip, SQL Server Management Studio eller MySQL Workbench har innebygde formatterere. De er kraftige og integreres direkte med databasetilkoblingene dine.
Kompromisset: de krever installasjon og oppsett. DataGrip koster $199/år for enkeltpersoner. SSMS er gratis, men kun for Windows. Hvis du trenger rask formattering uten å installere noe, eller du jobber på tvers av flere databasesystemer, er et nettleserbasert verktøy mer praktisk.
Editor-utvidelser
Hvis du skriver SQL i VS Code eller Sublime Text, gir utvidelser som SQL Beautify eller SqlBeautifier formattering i editoren din. Dette fungerer godt når du aktivt skriver spørringer og ønsker umiddelbar formattering som en del av arbeidsflyten din.
Begrensningen: utvidelser trenger konfigurasjon, og de er knyttet til din spesifikke editor. Når du deler SQL med teammedlemmer eller legger ut spørringer i dokumentasjon, sikrer en standardisert nettformatterer at alle ser samme formattering.
Kommandolinje-formatterere
Verktøy som sqlformat (Python) eller sql-formatter-cli (Node.js) kan integreres i CI/CD-pipeline for automatisk å formatere SQL i versjonskontroll. Dette sikrer konsistens på tvers av et team.
Best brukt for automatiserte arbeidsflyter fremfor ad-hoc-formattering. Hvis du bare rydder opp i noen få spørringer eller lærer SQL, legger kommandolinje-verktøy unødvendig kompleksitet til.
Hvordan SQL-formatering ble standard praksis
SQL ble utviklet ved IBM på 1970-tallet, men formateringskonvensjoner dukket opp mye senere. Tidlig SQL var funksjonell, men inkonsekvent—hver utvikler formaterte spørringer forskjellig.
Vendepunktet kom på 1990-tallet da databaser gikk fra enkeltdevelopment-prosjekter til teambasert utvikling. Organisasjoner begynte å lage interne SQL-stilguider for å opprettholde konsistens. Når fem utviklere jobbet på samme database, ble lesbar SQL avgjørende for samarbeid.
2000-tallet brakte ORMs som genererte SQL automatisk. Disse verktøyene produserte fungerende, men stygg SQL—alt på én linje, ingen innrykk. Dette skapte etterspørsel etter automatiske formateringsverktøy som kunne gjøre generert SQL lesbar for mennesker.
Online SQL-formaterere dukket opp på 2010-tallet ettersom webutvikling modnet. I stedet for å installere verktøy eller konfigurere IDE-plugins, kunne utviklere formatere SQL i en nettleser. Dette demokratiserte tilgangen til riktig formatering for alle—fra nybegynnere som lærer SQL til erfarne utviklere som rydder opp i raske spørringer.
I dag regnes SQL-formatering som en grunnleggende praksis, tilsvarende kodeformatering i andre programmeringsspråk. SQL Style Guide av Simon Holywell gir bredt aksepterte konvensjoner, og verktøy som dette implementerer disse standardene automatisk.
Kodeeksempler
Eksempel 1: Grunnleggende SELECT-spørring
Uformatert:
1select id, first_name, last_name, email from customers where status = 'active' order by last_name, first_name;
2Formatert:
1SELECT
2 id,
3 first_name,
4 last_name,
5 email
6FROM
7 customers
8WHERE
9 status = 'active'
10ORDER BY
11 last_name,
12 first_name;
13Eksempel 2: JOIN-spørring
Uformatert:
1select c.id, c.name, o.order_date, o.total_amount from customers c left join orders o on c.id = o.customer_id where o.order_date >= '2023-01-01' and o.status != 'cancelled' order by o.order_date desc;
2Formatert:
1SELECT
2 c.id,
3 c.name,
4 o.order_date,
5 o.total_amount
6FROM
7 customers c
8 LEFT JOIN orders o ON c.id = o.customer_id
9WHERE
10 o.order_date >= '2023-01-01'
11 AND o.status != 'cancelled'
12ORDER BY
13 o.order_date DESC;
14Eksempel 3: Kompleks spørring med underspørring
Uformatert:
1select d.department_name, (select count(*) from employees e where e.department_id = d.id) as employee_count, (select avg(salary) from employees e where e.department_id = d.id) as avg_salary from departments d where d.active = true having employee_count > 0 order by avg_salary desc;
2Formatert:
1SELECT
2 d.department_name,
3 (
4 SELECT
5 COUNT(*)
6 FROM
7 employees e
8 WHERE
9 e.department_id = d.id
10 ) AS employee_count,
11 (
12 SELECT
13 AVG(salary)
14 FROM
15 employees e
16 WHERE
17 e.department_id = d.id
18 ) AS avg_salary
19FROM
20 departments d
21WHERE
22 d.active = TRUE
23HAVING
24 employee_count > 0
25ORDER BY
26 avg_salary DESC;
27Programmatisk SQL-formatering
Her er eksempler på hvordan man implementerer SQL-formatering i forskjellige programmeringsspråk:
1// JavaScript SQL-formateringseksempel ved bruk av sql-formatter-bibliotek
2const sqlFormatter = require('sql-formatter');
3
4function formatSQL(sql) {
5 return sqlFormatter.format(sql, {
6 language: 'sql',
7 uppercase: true,
8 linesBetweenQueries: 2,
9 indentStyle: 'standard'
10 });
11}
12
13const rawSQL = "select id, name from users where status='active'";
14const formattedSQL = formatSQL(rawSQL);
15console.log(formattedSQL);
161# Python SQL-formateringseksempel ved bruk av sqlparse
2import sqlparse
3
4def format_sql(sql):
5 return sqlparse.format(
6 sql,
7 reindent=True,
8 keyword_case='upper',
9 identifier_case='lower',
10 indent_width=2
11 )
12
13raw_sql = "select id, name from users where status='active'"
14formatted_sql = format_sql(raw_sql)
15print(formatted_sql)
161// Java SQL-formateringseksempel ved bruk av JSqlParser
2import net.sf.jsqlparser.parser.CCJSqlParserUtil;
3import net.sf.jsqlparser.statement.Statement;
4
5public class SQLFormatter {
6 public static String formatSQL(String sql) throws Exception {
7 Statement statement = CCJSqlParserUtil.parse(sql);
8 return statement.toString()
9 .replaceAll("(?i)SELECT", "\nSELECT")
10 .replaceAll("(?i)FROM", "\nFROM")
11 .replaceAll("(?i)WHERE", "\nWHERE")
12 .replaceAll("(?i)ORDER BY", "\nORDER BY");
13 }
14
15 public static void main(String[] args) throws Exception {
16 String rawSQL = "select id, name from users where status='active'";
17 String formattedSQL = formatSQL(rawSQL);
18 System.out.println(formattedSQL);
19 }
20}
211<?php
2// PHP SQL-formateringseksempel
3function formatSQL($sql) {
4 // Erstatt nøkkelord med store bokstaver
5 $keywords = ['SELECT', 'FROM', 'WHERE', 'JOIN', 'LEFT JOIN', 'RIGHT JOIN',
6 'INNER JOIN', 'GROUP BY', 'ORDER BY', 'HAVING', 'LIMIT'];
7
8 $formattedSQL = $sql;
9 foreach ($keywords as $keyword) {
10 $formattedSQL = preg_replace('/\b' . preg_quote($keyword, '/') . '\b/i', "\n$keyword", $formattedSQL);
11 }
12
13 // Legg til innrykk
14 $lines = explode("\n", $formattedSQL);
15 $result = '';
16 $indentLevel = 0;
17
18 foreach ($lines as $line) {
19 $trimmedLine = trim($line);
20 if (!empty($trimmedLine)) {
21 $result .= str_repeat(" ", $indentLevel) . $trimmedLine . "\n";
22 }
23 }
24
25 return $result;
26}
27
28$rawSQL = "select id, name from users where status='active'";
29$formattedSQL = formatSQL($rawSQL);
30echo $formattedSQL;
31?>
32Ofte stilte spørsmål
Fungerer denne SQL-formatteringen med PostgreSQL, MySQL og SQL Server?
Ja, den håndterer standard SQL-syntaks som er vanlig på tvers av store databaser—PostgreSQL, MySQL, SQL Server (T-SQL), Oracle, SQLite og MariaDB. Formatteringen fokuserer på kjerne-SQL som fungerer overalt: SELECT, JOIN, WHERE, GROUP BY, og så videre.
Databasespesifikke funksjoner blir kanskje ikke formatert perfekt. For eksempel PostgreSQL's array-syntaks eller SQL Server's proprietære funksjoner får kanskje ikke spesiell formatteringsbehandling, men de vil heller ikke ødelegge formatteringen. Spørringen vil fortsatt være mer lesbar enn før.
Sendes SQL-koden min til en server?
Nei. Alt skjer i nettleseren din. Lim inn SQL-en din, og den formateres lokalt uten noen nettverksforespørsler. Dine spørringer forlater aldri maskinen din.
Dette er viktig når du jobber med produksjonsdatabase-skjemaer eller proprietær forretningslogikk. Det er ingen risiko for at sensitiv informasjon blir logget eller lagret på noen andres server.
Kan validatoren fange alle SQL-feil?
Langt i fra. Den fanger strukturelle og syntaktiske problemer—manglende parenteser, uavsluttede anførselstegn, setninger i feil rekkefølge. Det er alt.
Den vil ikke vite om tabellnavnene dine er feil, datatypene er inkompatible, eller om spørringen kommer til å ta 10 minutter å kjøre. For det trenger du din faktiske database. Tenk på denne validatoren som stavekontroll for SQL, ikke en fullstendig spørringsanalyse.
Hvorfor formatere SQL når databasen kjører den uansett?
Databaser bryr seg ikke om formattering—de analyserer spørringen uansett. Men mennesker bryr seg. Når du trenger å feilsøke en mislykket spørring, endre en eksisterende, eller gjennomgå noen andres SQL, gjør riktig formattering forskjellen mellom å forstå den på 30 sekunder versus 30 minutter.
Formatert SQL hjelper deg også med å oppdage logiske feil. Når strukturen er tydelig, kan du se om du har koblet tabeller feil eller plassert betingelser på feil sted.
Kan jeg tilpasse innrykk eller nøkkelordstype?
Ikke for øyeblikket. Formatteringen bruker standard konvensjoner: store bokstaver for nøkkelord, to-sifret innrykk, setninger på separate linjer. Disse følger SQL Style Guide som de fleste team bruker.
Hvis du trenger tilpasset formattering (forskjellig innrykksbredde, små bokstaver for nøkkelord), trenger du et konfigurerbart kommandolinje-verktøy som sqlformat eller en IDE med formatteringsinnstillinger.
Vil dette fungere med 1000-linjes lagrede prosedyrer?
Den vil formatere store spørringer, selv om svært komplekse lagrede prosedyrer (1000+ linjer) kan ta noen sekunder å behandle. Formatteringen håndterer SQL-en du limer inn, uavhengig av lengde.
For massive lagrede prosedyrer kan du ønske å dele dem opp i mindre deler eller bruke en databasespesifikk IDE som er optimalisert for store filer.
Endrer formattering hvordan spørringen min kjøres?
Nei. Formattering legger bare til mellomrom og endrer store/små bokstaver. Databasen ignorerer begge deler. Den formaterte spørringen returnerer nøyaktig samme resultater og kjøres med samme ytelse som den uformaterte versjonen.
Det eneste unntaket er hvis validatoren finner faktiske syntaksfeil (manglende parenteser, osv.), vil retting av disse endre atferd—men bare fra "kjører ikke" til "kjører korrekt".
Hvilken SQL-standard følger dette?
Formatteringen følger SQL-92-konvensjoner med utvidelser for vanlige funksjoner i SQL:1999 og senere standarder. Dette dekker SQL-en de fleste utviklere skriver daglig—SELECT-spørringer, joins, underspørringer, CASE-setninger, vindusfunksjoner.
Svært nye SQL-funksjoner fra SQL:2016 eller SQL:2019 blir kanskje ikke gjenkjent, men de vil ikke ødelegge formatteringen. Du vil bare få grunnleggende formattering i stedet for spesialisert behandling.
Kan jeg bruke dette for Oracle PL/SQL eller SQL Server T-SQL?
For grunnleggende spørringer, ja. For prosedural kode (PL/SQL-blokker, T-SQL lagrede prosedyrer med kontrollflyt), vil formatteringen være begrenset. Verktøyet fokuserer på SELECT, INSERT, UPDATE, DELETE-setninger og deres setninger.
Hvis du jobber mye med databasespesifikk prosedural kode, vil databasens innebygde IDE (SQL Developer for Oracle, SSMS for SQL Server) gi bedre formattering som forstår full syntaks.
Referanser og videre lesning
- SQL Stilguide av Simon Holywell - Standarden for SQL formateringskonvensjoner brukt av utviklingsteam
- ISO/IEC 9075 SQL Standard - Den offisielle internasjonale SQL-standardspesifikasjonen
- PostgreSQL SQL Syntaks Dokumentasjon - PostgreSQL's omfattende SQL syntaksreferanse
- Microsoft T-SQL Referanse - Offisiell dokumentasjon for SQL Server's T-SQL dialekt
- MySQL Referansehåndbok - MySQL's komplette SQL-setningsreferanse
Start Formatering av SQL
Lesbar SQL gjør feilsøking raskere, kodeanmeldelser enklere og samarbeid smidigere. Lim inn spørringen din over for å se den formatert i henhold til bransjestandardkonvensjoner—ingen installasjon, ingen konfigurasjon, ingen data som forlater nettleseren din.