Форматер/прикрасник SQL

Форматер/прикрасник SQL, це безплатний інструмент, який перетворює SQL-код на читабельнішу версію з послідовним форматуванням.

Що змінюється під час форматування SQL?

Форматування змінює вигляд запиту, щоб його конструкції, вирази та вкладені структури було легше читати. Зазвичай інструмент додає переноси рядків і відступи в списках SELECT, конструкціях JOIN, умовах WHERE, підзапитах і виразах CASE.

Форматування не повинно змінювати очікуваний результат запиту. Однак діалекти SQL відрізняються, а саме лише форматування не гарантує збереження змісту конструкції. Перевіряй згенерований SQL перед виконанням із робочими даними, особливо якщо в ньому є оператори певного постачальника, процедурні розширення або незвичні правила використання лапок.

Форматер стане в пригоді, коли потрібно прочитати сторонній запит, перевірити згенерований SQL, налагодити довгу конструкцію або підготувати код до запиту на злиття. Завдяки послідовному оформленню також простіше порівнювати зміни, оскільки зайвих відмінностей у пробілах стає менше.

Як відформатувати SQL-запит?

Встав або введи конструкцію в поле SQL, а потім надішли її, щоб отримати відформатовану версію в полі Прикрашений SQL. Вхідні дані надсилаються на сервер через HTTPS для обробки й не зберігаються.

1. Скопіюй конструкцію повністю, зокрема всі потрібні загальні табличні вирази, а в результаті перевір коментарі та завершальну крапку з комою, якщо вона була.
2. Введи її в поле SQL. За можливості не форматуйте окремі фрагменти.
3. Переглянь результат у полі Прикрашений SQL, звернувши особливу увагу на вкладені вирази та синтаксис конкретного діалекту.
4. Перед розгортанням виконай відформатовану конструкцію у відповідному середовищі розробки або проміжному середовищі.

Якщо працюєш із конфіденційними даними бази, перевір правила своєї організації, перш ніж надсилати текст запиту будь-якому серверному інструменту. Вилучи паролі, токени доступу, персональні дані та конфіденційні буквальні значення, якщо вони не потрібні для розуміння запиту.

Як читати прикрашений SQL?

Орієнтуйся на відступи та межі конструкцій, але не вважай нове оформлення доказом правильності запиту. Після того як кожна логічна частина отримає окремий рядок або рівень відступу, конструкції верхнього рівня SELECT, FROM, WHERE, GROUP BY та ORDER BY зазвичай буде легше розрізняти.

• Підзапити з відступами: показують, де зовнішня конструкція використовує внутрішній результат.
• Вирівняні умови: допомагають перевірити пріоритет AND і OR. За замовчуванням AND має вищий пріоритет за OR, а логічне групування, як і раніше, визначають дужки.
• Відокремлені конструкції JOIN: допомагають побачити, яка умова ON належить кожній таблиці.
• Розгорнуті списки SELECT: дають змогу легше помітити пропущені коми, дублікати стовпців і неоднозначні псевдоніми.
• Виразно оформлені гілки CASE: допомагають зіставити ключові слова WHEN, THEN, ELSE та END.

Рядки в лапках, числа, розділові знаки й коментарі мають значення в SQL, тому перевіряй їх, а не вважай суто елементами оформлення. Символи з діакритичними знаками або символи нелатинських абеток можуть бути допустимими в рядкових літералах та ідентифікаторах у лапках, залежно від бази даних і кодування символів.

Короткі приклади форматування

Розгляньмо такий компактний вхідний запит.

Вхід: SELECT id,name FROM customers WHERE active=1 ORDER BY name;

Читабельна відформатована версія може мати такий вигляд.

Результат: SELECT id, name

FROM customers

WHERE active = 1

ORDER BY name;

У запиті з об'єднанням таблиць відступи ще корисніші.

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

У читабельному результаті SELECT, FROM, JOIN, ON і WHERE можна розмістити на окремих рядках, зберігши порівняння o.total > 100. Точний регістр літер, пробіли та розташування рядків залежать від прийнятих правил форматування, тому ці приклади показують лише можливе оформлення, а не гарантований стиль.

Чи знаходить форматування помилки в SQL?

Ні. Прикрашання SQL не замінює перевірку парсером бази даних. Цей інструмент повертає відформатований SQL, тому не слід використовувати його як засіб перевірки синтаксису чи схеми або як планувальник виконання.

Утім, зрозуміліше оформлення може допомогти помітити ймовірні помилки під час перевірки. Серед типових прикладів є пропущена кома в списку SELECT, непарні дужки, незакритий рядок у лапках, JOIN без потрібної умови або неправильно згрупований вираз з AND чи OR. Також так простіше помітити зарезервоване слово, використане як ідентифікатор без лапок.

Деякі проблеми неможливо визначити без цільової бази даних. Конструкцію, яку приймає PostgreSQL, може знадобитися змінити для Microsoft SQL Server, MySQL, Oracle Database або SQLite. Для діагностики відсутніх таблиць, невідомих стовпців, несумісних типів даних і помилок дозволів зазвичай потрібен рушій бази даних або засіб розробки, що враховує конкретний діалект.

Коли форматувати SQL немає сенсу?

Форматування зазвичай зайве, якщо SQL уже оформлено послідовно або його оброблятиме лише машина. Повторне форматування згенерованих запитів може створити багато несуттєвих змін у системі керування версіями, не покращуючи генератор, який їх створив.

Також форматування може бути недоречним у таких ситуаціях:

• Файл міграції підписано, для нього обчислено контрольну суму або його в інший спосіб порівнюють побайтово.
• Мініфікований або компактний запит вбудовано в об'єкт із жорсткими обмеженнями на розмір, і його нікому не потрібно перевіряти.
• Зараз потрібно перевірити запит, проаналізувати план виконання або оптимізувати швидкодію, а не покращити читабельність.
• Запит містить конфіденційні значення, які правила організації забороняють надсилати серверному сервісу.

Для послідовного форматування всього репозиторію краще може підійти форматер командного рядка з підтримкою потрібного діалекту, адже його конфігурацію можна зберігати в репозиторії разом із кодом. Якщо SQL міститься у структурованому корисному навантаженні API, інструмент «Перевірка та форматування JSON» допоможе перевірити навколишній JSON, але сам SQL усе одно потребуватиме спеціалізованої обробки.

Поширені запитання

Чи змінить форматування поведінку NULL у SQL?

Пробіли та відступи не змінюють тризначну логіку SQL або поведінку NULL. Проте перевіряй вирази на кшталт column = NULL, де зазвичай потрібно використовувати IS NULL, адже форматер не виправить таку семантичну помилку.

Чи можна відформатувати кілька SQL-запитів одночасно?

Підтримку одночасного форматування кількох SQL-конструкцій не задокументовано. Форматуй кожну конструкцію окремо.

Чи безпечно залишати коментарі у вхідному запиті?

Коментарі можуть містити номери заявок, внутрішні імена хостів, дані клієнтів або робочі примітки, навіть якщо виконуваний SQL не містить конфіденційних літералів. Перевір як рядкові, так і блокові коментарі перед надсиланням тексту на сервер.

Як писати ключові слова SQL, великими чи малими літерами?

Зазвичай прийнятні обидва варіанти, оскільки багато рушіїв баз даних не враховують регістр ключових слів без лапок. Дотримуйся стилю, прийнятого в репозиторії, і будь обережний з ідентифікаторами в лапках, адже деякі бази даних зберігають або розрізняють їхній регістр.

Що перевірити перед виконанням відформатованого запиту?

Уточни діалект цільової бази даних, перевір умови WHERE і JOIN, а також межі транзакцій у конструкціях UPDATE, DELETE та командах, які змінюють схему. Ризиковані запити спочатку виконуй у базі даних для розробки або проміжному середовищі, бажано з репрезентативними даними й належними резервними копіями.