SQL-formatering & Validator - Formater SQL-forespørgsler Online Gratis
Gratis SQL-formatering og validator. Formater automatisk SQL med korrekt indrykning og store bogstaver. Tjek syntaksfejl øjeblikkeligt. Fungerer med MySQL, PostgreSQL, SQL Server, Oracle.
SQL Formatter & Validator
Formater og valider SQL-forespørgsler med automatisk indrykning, nøgleordsstore bogstaver og syntaksfejlregistrering.
Dokumentation
Hvorfor SQL-formatering er vigtig
Har du nogensinde arvet et databaseprojekt, hvor SQL'en ser ud, som om nogen har skrevet den med bind for øjnene? Du er ikke alene. Dårligt formateret SQL er en af de mest almindelige kilder til fejl og spildt tid i databaseudvikling.
Denne SQL-formatter og validator hjælper dig med at rydde op i rod-forespørgsler automatisk. Indsæt din SQL, og den anvender straks korrekt indrykning, sætter keywords med stort, og tjekker for syntaksfejl - alt sammen i din browser uden at sende data til nogen server. Det, der typisk tager 10-15 minutter manuel formatering, sker på sekunder.
Ud fra min erfaring med databaseteams er den største tidsbesparelse ikke kun formateringen - det er at fange fejl, før de rammer produktionen. En forkert placeret parentes eller en ikke-lukket citation kan spilde timer på fejlsøgning. Dette værktøj fanger disse problemer med det samme, før du eksekverer noget mod din database.
Sådan bruges SQL-formatteringen
Grænsefladen er bevidst minimal—bare indsæt og kør:
- Indsæt din SQL i inputfeltet (eller skriv direkte, hvis du skriver fra bunden)
- Se den formateres automatisk mens du skriver—ingen knapper at klikke på, ingen indstillinger at konfigurere
- Gennemgå valideringsfejl hvis nogle vises under den formaterede output
- Kopiér den formaterede SQL med ét klik for at bruge i din IDE, dokumentation eller databaseværktøj
Fungerer på enhver enhed med en browser. Formateringen sker udelukkende på klientsiden, så dine forespørgsler forlader aldrig din maskine—vigtigt når du arbejder med produktionsdatabasestrukturer eller følsomme skemaer.
Hvad SQL-formatteringen gør
Nøgleordsstore bogstaver
Alle SQL-nøgleord bliver automatisk skrevet med store bogstaver—SELECT, FROM, WHERE, JOIN og så videre. Dette følger konventionen, der bruges af de fleste databaseteams, og gør nøgleord visuelt adskilt fra dine tabel- og kolonnenavne. Når du gennemser en kompleks forespørgsel, hjælper denne visuelle adskillelse dig med at identificere forespørgselsstrukturen ved første blik.
Smart indrykning
Formatteringen strukturerer din SQL baseret på logisk hierarki snarere end blot at tilføje tilfældige linjeskift. Hovedklausuler som SELECT og FROM starter ved venstre margin. JOIN-klausuler rykkes ind under FROM for at vise, at de er en del af tabelvalget. Underforespørgsler får yderligere indrykningsniveauer, hvilket gør indlejret logik tydelig.
Her er, hvad der sker i praksis: når du har en forespørgsel med flere joins og underforespørgsler, lader korrekt indrykning dig se forespørgselsstrukturen uden at læse hvert ord. Du kan straks se, hvor et join slutter, og et nyt begynder, eller hvor en underforespørgsel bruges i din SELECT-liste.
Logiske linjeskift
Linjeskift vises, hvor de forbedrer læsbarheden, ikke bare overalt. Hver hovedklausul får sin egen linje. Elementer i kommaseparerede lister (som kolonnenavne i SELECT) får hver deres egen linje med korrekt indrykning. Underforespørgsler er visuelt adskilt. CASE-sætninger brydes ved WHEN, THEN og ELSE for klarhed.
Mellemrummet følger SQL-stilguide-konventionerne, der bruges i branchen, hvilket betyder, at din formaterede SQL vil se bekendt ud for andre udviklere.
SQL-validering: Hvad bliver tjekket
Validatoren fanger de fejl, der typisk slipper igennem, når du skriver SQL hurtigt. Den erstatter ikke din databases forespørgselsanalyse, men fanger almindelige fejl, før du overhovedet kører forespørgslen.
Strukturelle fejl
Ubalancerede parenteser er overraskende hyppige i komplekse forespørgsler med indlejrede underforespørgsler. Validatoren tæller åbne og lukkede parenteser for straks at markere uoverensstemmelser. Jeg har set produktionshændelser forårsaget af en enkelt manglende parentes i en 200-liniers forespørgsel—dette fanger dem tidligt.
Uafsluttede strenglitteraler sker, når du glemmer det afsluttende anførselstegn på en strengværdi. Din database vil straks afvise disse, men at fange dem her sparer en ekstra tur.
Klausul rækkefølge-problemer markeres, når klausuler optræder uden for sekvensen. For eksempel hvis du placerer HAVING før GROUP BY, eller WHERE efter GROUP BY, advarer validatoren dig. Dette følger SQL-standardens syntaksregler defineret i ISO/IEC 9075 SQL-standarden.
Logiske fejl
JOIN-klausuler uden ON-betingelser skaber utilsigtede cross joins, der returnerer langt flere rækker end tilsigtet. Et typisk scenarie: du tilføjer et tredje eller fjerde tabel til en forespørgsel og glemmer ON-klausulen. Uden denne kontrol opdager du måske ikke problemet, før du ser tusindvis af duplikerede rækker i dine resultater.
HAVING uden GROUP BY er teknisk set ugyldig SQL i de fleste databaser. HAVING-klausulen filtrerer grupperede resultater, så den kræver en GROUP BY for at fungere. Validatoren fanger denne logiske uoverensstemmelse.
Ufuldstændige WHERE-betingelser sker, når du begynder at skrive en betingelse, men ikke afslutter den—som WHERE status = uden nogen værdi. Disse er nemme at overse, når man redigerer forespørgsler.
Hvad den ikke vil fange
Denne validator fokuserer på syntaks og struktur, ikke databaseskema. Den vil ikke vide, om:
- Dine tabel- eller kolonnenavne eksisterer i din database
- Du joiner på kompatible datatyper
- Din forespørgsel vil udføre godt eller har optimeringsproblemer
- Du har tilladelse til at tilgå de tabeller, du forespørger
Tænk på den som en første gennemgang, før du sender forespørgslen til din faktiske database.
Formateringsregler Anvendt af Dette Værktøj
Formatteringen anvender konsistente regler baseret på SQL Style Guide konventioner, som de fleste databaseteams følger.
Nøgleord Skrives med Store Bogstaver
Hver SQL-nøgleord bliver skrevet med store bogstaver: 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 almindelige funktioner (COUNT, SUM, AVG, CASE, WHEN).
Hvorfor store bogstaver? Det skaber visuel adskillelse mellem SQL's sproglige elementer og dine database-specifikke navne (tabeller, kolonner, aliases). Når du scanner en forespørgsel, fanger dit øje øjeblikkeligt strukturen.
To-Spaces Indrykning pr. Niveau
Hovedklausuler som SELECT og FROM starter ved venstre margin. JOIN-klausuler rykkes to mellemrum ind under FROM for at vise, at de er en del af tabelvalget. Underforespørgsler rykkes yderligere to mellemrum ind for hver indlejringsniveau. Dette skaber et visuelt hierarki, der matcher den logiske struktur.
Kommaseparerede lister (kolonnenavne i SELECT, for eksempel) får hver deres egen linje med konsistent indrykning. Når du har 15 kolonner i din SELECT-liste, gør dette det nemt at scanne og finde specifikke kolonner.
Betingelser i WHERE-klausuler justeres lodret. Når du har flere AND- eller OR-betingelser, gør justering den logiske struktur umiddelbart tydelig.
Før og Efter: Se Forskellen
Før Formattering:
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;
2Efter Formattering:
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: Hvad Bliver Markeret
Validatoren tjekker strukturel integritet og grundlæggende logisk konsistens. Her er hvad den ser efter:
Strukturelle Tjek
Balancerede parenteser: Åbne og lukkede parenteser skal matche. Indlejrede delforespørgsler har ofte flere niveauer af parenteser, og fejltælling er en af de mest almindelige SQL-fejl. Validatoren tæller dem for dig.
Korrekt lukkede strenge: Hver åbningscitationstegn (enkelt eller dobbelt) skal have et lukkende citationstegn. Det lyder indlysende, men når du skriver en kompleks forespørgsel med flere strenglitteraler, er det let at overse en.
Korrekt klausulrækkefølge: SQL har specifikke rækkefø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. At placere dem uden for sekvensen forårsager øjeblikkelige syntaksfejl. Validatoren tjekker denne rækkefølge baseret på SQL-standarden.
Logiske Konsistenstjek
JOIN med ON-betingelse: Hver JOIN har brug for en ON- eller USING-klausul for at angive, hvordan tabeller relaterer. Uden den får du et cross join—hver række fra en tabel parret med hver række fra en anden tabel. Det er sjældent det, du vil, og indikerer typisk en manglende ON-klausul.
Fuldstændige WHERE-betingelser: En WHERE-klausul har brug for fuldstændige prædikater. WHERE status = uden en værdi er ufuldstændig og ugyldig. Validatoren markerer disse delvise betingelser.
HAVING kræver GROUP BY: HAVING-klausulen filtrerer grupperede resultater, så den giver kun mening, når du har en GROUP BY. Brug af HAVING uden GROUP BY er en logisk fejl, som de fleste databaser afviser.
GROUP BY aggregeringsregler: Når du bruger aggregeringsfunktioner som COUNT() eller SUM(), skal alle ikke-aggregerede kolonner i din SELECT-liste fremgå i GROUP BY. Dette er et grundlæggende SQL-krav, som validatoren tjekker.
Eksempel på Almindelige Fejl Fanget
Her er SQL med flere problemer, som validatoren ville markere:
1SELECT user_id, COUNT(*) FROM orders
2JOIN users
3WHERE status =
4GROUP BY
5HAVING count > 10;
6Fundne problemer:
JOIN usersmanglerON-betingelse (vil oprette cross join)WHERE status =ufuldstændig (ingen sammenligningsværdi)- Tom
GROUP BY-klausul (ingen kolonner specificeret) HAVING count > 10refererer til udefineret kolonne
Hvornår man bruger denne SQL-formatter
Under Kodeanmeldelser
Har du nogensinde prøvet at gennemgå en 50-linjet SQL-forespørgsel, der er skrevet på en enkelt linje? Det er brutalt. Inden du indsender forespørgsler til kodeanmeldelse, skal du køre dem gennem formatteren. Dine anmeldere vil takke dig, og de vil faktisk kunne fokusere på logik i stedet for at skulle afkode strukturen.
Når du gennemgår pull requests med databaseændringer, så bed bidragyderne om at formatere deres SQL først. Det gør det meget nemmere at opdage logiske fejl, når strukturen er konsistent.
Fejlfinding i Produktionsmiljø
Når du fejlfinder en fejlende forespørgsel i produktionen, hjælper korrekt formatering dig med at se strukturen tydeligt. Jeg har fejlfundet talrige forespørgsler, hvor problemet blev åbenlyst, så snart SQL'en var korrekt formateret - en manglende join-betingelse, en ukorrekt WHERE-klausul gruppering eller en underspørgsel det forkerte sted.
Kopier forespørgslen fra dine logs, indsæt den her, og du vil straks se, om der er strukturelle problemer.
Arbejde med Genereret SQL
ORMs (Object-Relational Mappers) som Hibernate, Entity Framework eller SQLAlchemy genererer SQL automatisk. Nogle gange har du brug for at se, hvilken forespørgsel de faktisk producerer. Den genererede SQL er som regel én lang linje uden formatering. Dette værktøj gør ORM-genereret forespørgsler læsbare, så du kan forstå og optimere dem.
Undervisning og Læring af SQL
Hvis du lærer SQL eller underviser i det, hjælper denne formatter dig med at forstå den korrekte forespørgselsstruktur. Når du indsætter en fungerende forespørgsel og ser, hvordan den formateres, lærer du konventionerne. Når du indsætter en ødelagt forespørgsel og ser valideringsfejlene, forstår du, hvorfor den ikke virker.
Migrering Mellem Databasesystemer
Forskellige databaser (PostgreSQL, MySQL, SQL Server) har let forskellige SQL-dialekter. Når du migrerer forespørgsler mellem systemer, hjælper korrekt formatering dig med at opdage dialekt-specifikke syntakser, der muligvis kræver justeringer. Formatteren følger standard SQL-konventioner, der fungerer på tværs af de fleste store databaser.
Alternativer til denne SQL-formatter
Database-Specifikke IDE'er
Værktøjer som DataGrip, SQL Server Management Studio eller MySQL Workbench har indbyggede formattere. De er kraftfulde og integrerer direkte med dine databaseforbindelser.
Kompromisset: de kræver installation og opsætning. DataGrip koster 199 USD/år for enkeltpersoner. SSMS er gratis, men kun til Windows. Hvis du har brug for hurtig formattering uden installation, eller du arbejder på tværs af flere databasesystemer, er et browserbaseret værktøj mere praktisk.
Editor-udvidelser
Hvis du skriver SQL i VS Code eller Sublime Text, bringer udvidelser som SQL Beautify eller SqlBeautifier formattering ind i din editor. Dette fungerer godt, når du aktivt skriver forespørgsler og ønsker øjeblikkelig formattering som en del af din arbejdsgang.
Begrænsningen: udvidelser kræver konfiguration, og de er knyttet til din specifikke editor. Når du deler SQL med teammedlemmer eller poster forespørgsler i dokumentation, sikrer en standardiseret webformatter, at alle ser den samme formattering.
Kommandolinjeformattere
Værktøjer som sqlformat (Python) eller sql-formatter-cli (Node.js) kan integreres i CI/CD-pipelines for automatisk at formatere SQL i versionsstyring. Dette sikrer konsistens på tværs af et team.
Bedst brugt til automatiserede workflows snarere end ad hoc-formattering. Hvis du blot rydder op i nogle få forespørgsler eller lærer SQL, tilføjer kommandolinjeværktøjer unødvendig kompleksitet.
Hvordan SQL-formatering blev standard praksis
SQL blev udviklet hos IBM i 1970'erne, men formateringskonventioner dukkede op meget senere. Tidlig SQL var funktionel, men inkonsekvent - hver udvikler formaterede forespørgsler anderledes.
Vendepunktet kom i 1990'erne, da databaser gik fra enkeltudvikler-projekter til teambaseret udvikling. Organisationer begyndte at oprette interne SQL-stilguides for at opretholde konsistens. Når fem udviklere arbejdede på samme database, blev læsbar SQL afgørende for samarbejde.
2000'erne bragte ORMs, der genererede SQL automatisk. Disse værktøjer producerede fungerende, men grimme SQL - alt på én linje, ingen indrykning. Dette skabte efterspørgsel efter automatiske formatteringer, der kunne gøre genereret SQL menneskeligt læsbar.
Online SQL-formatteringer dukkede op i 2010'erne, efterhånden som webudvikling modnes. I stedet for at installere værktøjer eller konfigurere IDE-plugins kunne udviklere formatere SQL i en browser. Dette demokratiserede adgangen til korrekt formatering for alle fra begyndere, der lærer SQL, til erfarne udviklere, der rydder op i hurtige forespørgsler.
I dag betragtes SQL-formatering som en grundlæggende praksis, svarende til kodningsformatering i andre programmeringssprog. SQL Style Guide af Simon Holywell giver bredt accepterede konventioner, og værktøjer som dette implementerer disse standarder automatisk.
Kodeeksempler
Eksempel 1: Grundlæggende SELECT-forespørgsel
Uformateret:
1select id, first_name, last_name, email from customers where status = 'active' order by last_name, first_name;
2Formateret:
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-forespørgsel
Uformateret:
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;
2Formateret:
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 forespørgsel med underforespørgsel
Uformateret:
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;
2Formateret:
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 forskellige programmeringssprog:
1// JavaScript SQL-formaterings eksempel ved brug af 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-formaterings eksempel ved brug af 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-formaterings eksempel ved brug af 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-formaterings eksempel
3function formatSQL($sql) {
4 // Erstat nøgleord med store bogstaver
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 // Tilføj indrykning
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 stillede spørgsmål
Virker denne SQL-formatter med PostgreSQL, MySQL og SQL Server?
Ja, den håndterer standard SQL-syntaks, der er common på tværs af store databaser—PostgreSQL, MySQL, SQL Server (T-SQL), Oracle, SQLite og MariaDB. Formatteren fokuserer på kernen af SQL, der virker overalt: SELECT, JOIN, WHERE, GROUP BY og så videre.
Database-specifikke funktioner bliver måske ikke formateret perfekt. For eksempel vil PostgreSQL's array-syntaks eller SQL Server's proprietære funktioner muligvis ikke få særlig formattering, men de vil heller ikke ødelægge formatteren. Forespørgslen vil stadig være mere læsbar end før.
Sendes min SQL-kode til en server?
Nej. Alt sker i din browser. Indsæt din SQL, og den formateres lokalt uden nogen netværksanmodninger. Dine forespørgsler forlader aldrig din maskine.
Dette er vigtigt, når du arbejder med produktionsdatabase-skemaer eller proprietær forretningslogik. Der er ingen risiko for, at følsomme oplysninger bliver logget eller gemt på andres server.
Kan validatoren fange alle SQL-fejl?
Langt fra. Den fanger strukturelle og syntaksmæssige problemer—manglende parenteser, uafsluttede citater, sætninger i forkert rækkefølge. Det er det hele.
Den ved ikke, om dine tabelnavn er forkerte, om dine datatyper er inkompatible, eller om din forespørgsel vil tage 10 minutter at køre. Til det har du brug for din faktiske database. Tænk på denne validator som stavekontrol for SQL, ikke en fuld forespørgselsanalyse.
Hvorfor formatere SQL, når min database alligevel kører den?
Databaser er ligeglade med formattering—de fortolker forespørgslen uanset. Men mennesker er ikke. Når du skal fejlfinde en fejlende forespørgsel, ændre en eksisterende eller gennemgå en andens SQL, gør korrekt formattering forskellen mellem at forstå den på 30 sekunder versus 30 minutter.
Formateret SQL hjælper dig også med at opdage logiske fejl. Når strukturen er klar, kan du se, om du har joinet tabeller forkert eller placeret betingelser det forkerte sted.
Kan jeg tilpasse indrykning eller nøgleordstype?
Ikke i øjeblikket. Formatteren bruger standard konventioner: store bogstaver til nøgleord, to-spaces indrykning, sætninger på separate linjer. Disse følger SQL Style Guide, som de fleste teams bruger.
Hvis du har brug for brugerdefineret formattering (anden indrykninsbredde, små bogstaver til nøgleord), har du brug for et konfigurerbart kommandolinjeværktøj som sqlformat eller en IDE med formateringsindstillinger.
Virker dette med 1000-liniers lagrede procedurer?
Den formaterer store forespørgsler, selvom meget komplekse lagrede procedurer (1000+ linjer) måske tager et par sekunder at behandle. Formatteren håndterer den SQL, du indsætter, uanset længde.
Til massive lagrede procedurer kan du måske ville opdele dem i mindre dele eller bruge en database-specifik IDE, der er optimeret til store filer.
Ændrer formattering hvordan min forespørgsel eksekveres?
Nej. Formattering tilføjer kun mellemrum og ændrer store/små bogstaver. Din database ignorerer begge dele. Den formaterede forespørgsel returnerer præcis samme resultater og kører med samme ydeevne som den uformaterede version.
Den eneste undtagelse er, hvis validatoren finder faktiske syntaksfejl (manglende parenteser osv.), vil rettelse af disse ændre adfærd—men kun fra "kører ikke" til "kører korrekt".
Hvilken SQL-standard følger dette?
Formatteren følger SQL-92 konventioner med udvidelser for almindelige funktioner i SQL:1999 og nyere standarder. Dette dækker den SQL, de fleste udviklere skriver dagligt—SELECT-forespørgsler, joins, underforespørgsler, CASE-sætninger, vinduefunktioner.
Meget nye SQL-funktioner fra SQL:2016 eller SQL:2019 bliver måske ikke genkendt, men de vil ikke ødelægge formatteren. Du får blot grundlæggende formattering i stedet for specialiseret håndtering.
Kan jeg bruge dette til Oracle PL/SQL eller SQL Server T-SQL?
For grundlæggende forespørgsler, ja. For proceduremæssig kode (PL/SQL-blokke, T-SQL lagrede procedurer med kontrolflow) vil formatteringen være begrænset. Værktøjet fokuserer på SELECT, INSERT, UPDATE, DELETE-sætninger og deres klausuler.
Hvis du arbejder meget med database-specifik proceduremæssig kode, vil din databases native IDE (SQL Developer til Oracle, SSMS til SQL Server) give bedre formattering, der forstår den fulde syntaks.
Referencer og yderligere læsning
- SQL Stilguide af Simon Holywell - Den facto standard for SQL formaterings konventioner brugt af udviklingshold
- ISO/IEC 9075 SQL Standard - Den officielle internationale SQL standard specifikation
- PostgreSQL SQL Syntaks Dokumentation - PostgreSQL's omfattende SQL syntaks reference
- Microsoft T-SQL Reference - Officiel dokumentation for SQL Server's T-SQL dialekt
- MySQL Referencehåndbog - MySQL's komplette SQL statement reference
Start Formatering af SQL
Læsbar SQL gør fejlretning hurtigere, kodeanmeldelser nemmere og samarbejde mere gnidningsfrit. Indsæt din forespørgsel ovenfor for at se den formateret efter branchestandarder - ingen installation, ingen konfiguration, ingen data forlader din browser.