Прескочи към съдържанието

SQL форматиращ & валидиращ инструмент - Форматирайте SQL заявки онлайн безплатно

Безплатен SQL форматиращ и валидиращ инструмент. Автоматично форматирайте SQL със правилни отстъпи и главни букви. Проверявайте синтактични грешки мигновено. Работи с MySQL, PostgreSQL, SQL Server, Oracle.

SQL форматиране и валидация

Форматирайте и валидирайте SQL заявки с автоматично отстъпване, главни букви за ключови думи и откриване на синтактични грешки.

Въведете SQL заявка, за да видите форматирания резултат.
Калкулатор за зареждане...
📚

Документация

Какво представляват форматирането и валидирането на SQL?

Форматиращият инструмент за SQL пренаписва SQL заявка с последователни интервали, нови редове и изписани с главни букви ключови думи, за да се чете по-лесно. Валидаторът за SQL проверява същата заявка за структурни грешки, като незатворена кавичка или липсваща скоба, без да се свързва с база данни. Този инструмент прави и двете. Той работи изцяло в браузъра, така че текстът на заявката никога не се изпраща към сървър.

Как се форматира SQL заявка

  1. Поставете или въведете SQL заявка в полето за въвеждане.
  2. Форматираната версия се появява автоматично вдясно, без да е необходимо да натискате бутон.
  3. Всички грешки при валидирането се показват в списък под резултата.
  4. Бутонът за копиране изпраща форматираната заявка в клипборда.

Правила за форматиране на SQL

Изписване на ключовите думи с главни букви

Форматиращият инструмент изписва с главни букви фиксиран списък от ключови думи на SQL навсякъде, където те се срещат извън низ или заграден в кавички идентификатор. Ключовите думи в SQL не зависят от регистъра, затова това променя външния вид на заявката, но не и действието ѝ. Списъкът включва основните клаузи (SELECT, FROM, WHERE, GROUP BY, ORDER BY, HAVING, LIMIT, OFFSET), думите за съединяване на таблици (JOIN, LEFT, RIGHT, INNER, OUTER, FULL, ON), видовете команди (INSERT, UPDATE, DELETE, CREATE, ALTER, DROP) и често използваните оператори и свързващи думи (AND, OR, NOT, IN, BETWEEN, LIKE, AS, CASE, WHEN, THEN, ELSE, END, UNION, DISTINCT, VALUES, SET и още няколко).

Някои думи, които приличат на ключови, се оставят така, както са въведени. Агрегатните функции като COUNT, SUM и AVG не са в списъка, затова count(*) остава с малки букви, ако е въведено с малки букви. Думите за посока на сортиране ASC и DESC, както и литералите TRUE, FALSE и NULL, когато стоят самостоятелно, също не се променят. Текстът в низов литерал ('...'), в идентификатор в кавички ("...", обратните апострофи на MySQL `...` или квадратните скоби на SQL Server [...]) или в коментар никога не се променя, независимо от съдържанието му.

Нови редове и отстъпи

Всяка основна клауза започва на нов ред при левия край: SELECT, FROM, WHERE, GROUP BY, ORDER BY, HAVING, LIMIT и OFFSET. JOIN (и неговите варианти като LEFT JOIN) също започва на нов ред. CASE, WHEN, THEN, ELSE и END започват всяка на нов ред, а UNION (или UNION ALL, които се държат заедно на един ред) се отделя с празни редове. Всяка запетая също води до нов ред, така че списъкът с колони в SELECT или GROUP BY излиза с по една колона на ред.

Отстъп се появява само вътре в скоби. Съдържанието на подзаявка или на групиран израз се отстъпва с два интервала за всяко ниво на влагане. Заявка без скоби се форматира така, че всяка клауза да е долепена до левия край, без никакъв отстъп.

Пример: преди и след форматиране

Преди:

1select id, first_name, last_name, email from customers where status = 'active' order by last_name, first_name;
2

След:

1SELECT id,
2first_name,
3last_name,
4email
5FROM customers
6WHERE status = 'active'
7ORDER BY last_name,
8first_name;
9

Всички ключови думи са с главни букви, а всяка клауза и колона са на отделен ред. Тъй като заявката няма скоби, нито един ред не е с отстъп.

Скобите променят това. При форматиране на (select count(*) from employees e where e.department_id = d.id) като част от по-голяма заявка вътрешните SELECT, FROM и WHERE получават отстъп от два интервала, а count остава с малки букви, защото е име на функция, а не ключова дума от списъка.

Какво проверява валидаторът за SQL

Валидаторът търси структурни проблеми, без да се свързва с база данни:

  • Незатворени кавички. Единична или двойна кавичка, която е отворена, но никога не е затворена.
  • Несъответстващи скоби. Броят на ( и ) извън низове и коментари трябва да съвпада.
  • Подзаявки без скоби. SELECT, вложен в друг SELECT ... FROM ... SELECT шаблон, който не е обгърнат в ( ).
  • WHERE, започваща с AND или OR. Свързващ оператор в началото, преди който няма нищо.
  • JOIN без съответстващо условие. На JOIN му е необходима клауза ON или USING. CROSS JOIN и NATURAL JOIN са изключение, тъй като не приемат такава клауза.
  • Празен GROUP BY или ORDER BY. Ключовата дума на клаузата е без колони след себе си в края на заявката.
  • Непълно условие в WHERE. Незавършено сравнение като WHERE status = без стойност или самостоятелно WHERE без нищо след него в края на заявката.
  • SELECT без FROM. Отбелязва се само когато списъкът за избор съдържа обикновени имена на колони; израз, извикване на функция или литерал след SELECT е валиден сам по себе си и не се отбелязва.
  • Ред на клаузите. Проверяват се две конкретни условия: GROUP BY не трябва да стои преди WHERE, а ORDER BY не трябва да стои преди GROUP BY. Проверките се извършват на най-високото ниво на заявката, като се игнорира съдържанието на подзаявките.

Какво не проверява

Валидаторът не знае дали таблиците или колоните действително съществуват, дали съединените колони имат съвместими типове, нито как ще се изпълни заявката по отношение на производителността. Той не отбелязва и всяко правило, което налага една реална база данни. Два примера: HAVING без GROUP BY се приема, защото наличието на HAVING превръща заявката в групирана дори без GROUP BY, затова валидаторът не издава грешка за това. Също така той не проверява дали всяка неагрегирана колона в списъка на SELECT се среща и в GROUP BY. Много бази данни налагат това правило, но този инструмент не го проверява. Липсващата завършваща точка и запетая също не се отбелязва, тъй като точката и запетаята е разделител между командите, а не част от една заявка.

Пример: грешки, които валидаторът открива

1SELECT id FROM orders
2JOIN users
3WHERE status =
4

Тази заявка поражда две грешки:

  1. „Едно или повече съединения JOIN нямат условие ON.“ JOIN users няма клауза ON или USING.
  2. „Условието WHERE е непълно.“ status = няма стойност след знака за равенство.

Често задавани въпроси

Съвместим ли е този инструмент с MySQL, PostgreSQL, SQL Server и Oracle?

Той обработва основния синтаксис на SQL, споделян от тези бази данни: SELECT, JOIN, WHERE, GROUP BY и подобни клаузи. Специфичният за дадена база данни синтаксис, например литерали на масиви в PostgreSQL или процедурни блокове на T-SQL, няма да попречи на форматирането, но може да не получи специална обработка.

Изпраща ли се SQL заявката към сървър?

Не. Форматирането и валидирането се извършват в браузъра. Текстът на заявката не се предава никъде.

Изписва ли имената на функции като COUNT, SUM и AVG с главни букви?

Не. С главни букви се изписват само ключови думи на клаузи, думи за съединяване и фиксиран списък от оператори. Имената на функции като count, sum и avg, както и думите asc, desc, true, false и null, се оставят точно както са въведени.

Отбелязва ли валидаторът HAVING, използван без GROUP BY?

Не. Клауза HAVING без GROUP BY групира целия резултат в една-единствена група, което е валиден SQL, затова валидаторът не я третира като грешка.

Може ли валидаторът да открие всяка грешка в SQL?

Не. Той проверява структурата: скоби, кавички, няколко правила за реда на клаузите и някои често срещани логически пропуски, като например JOIN без условие. Не проверява имена на таблици или колони, типове данни и производителност на заявката. За да се потвърди, че заявката се изпълнява правилно, все пак е необходима връзка с реална база данни.

Променя ли форматирането начина, по който се изпълнява заявката?

Не. Форматирането променя само празните места и изписването с главни букви на ключови думи извън кавички. Всичко в низ, идентификатор в кавички или коментар се копира без промяна, така че заявката означава точно същото като преди.

Източници

  1. PostgreSQL Global Development Group. Lexical Structure. postgresql.org — ключовите думи не зависят от регистъра.
  2. Oracle. MySQL 8.0 Reference Manual: Schema Object Names. dev.mysql.com — обратният апостроф е символът за кавички на идентификатори в MySQL.
  3. Microsoft. Database Identifiers. learn.microsoft.com — ограничените идентификатори в SQL Server използват квадратни скоби или двойни кавички.
  4. PostgreSQL Global Development Group. SELECT. postgresql.org — HAVING прави заявката групирана и без GROUP BY.