Форматування SQL-запитів _

Як працює форматування SQL

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

1. Оберіть діалект. Зворотні лапки MySQL, касти :: PostgreSQL, шляхи таблиць з крапкою BigQuery і ідентифікатори в квадратних дужках T-SQL — кожен потребує токенайзера, що знає про них. Селектор діалекту вибирає, яку граматику застосовувати.
2. Токенізація введення. Форматер розбиває запит на потік токенів: ключові слова (SELECT, JOIN), ідентифікатори, літерали, оператори, дужки та коментарі. Рядкові літерали та ідентифікатори в лапках передаються без змін, щоб синтаксис, специфічний для діалекту, залишався робочим.
3. Застосування правил компонування. Клаузи верхнього рівня (SELECT, FROM, WHERE, GROUP BY, ORDER BY) починаються на власному рядку. Розділені комами вирази в списку select та списках стовпців отримують окремий рядок із відступом обраної одиниці.
4. Застосування регістру ключових слів. Перемикач регістру ключових слів переписує розпізнані SQL-ключові слова у верхній регістр, нижній регістр або зберігає оригінальний регістр введення. Ідентифікатори ніколи не торкаються — назви стовпців і таблиць завжди залишаються такими, як написані.
5. Генерація відформатованого рядка. Потік токенів об'єднується назад в один рядок із символом відступу (2 пробіли, 4 пробіли або табуляція) і налаштованим правилом переносу рядка. Живий режим перезапускає весь конвеєр із затримкою 200 мс під час введення.

Навіщо форматувати SQL

• Читабельність diff pull request. 200-рядковий CTE, переписаний в один рядок, перетворює code review на гру в здогадки. Узгоджене форматування утримує diff у рамках фактично внесеної зміни — новий стовпець, додатковий JOIN, інший предикат WHERE — щоб рецензент міг побачити це без розплутування пробілів.
• Простіше налагодження. Коли запит повертає неправильну кількість рядків, перше, що ви робите — читаєте його рядок за рядком. Відформатований SQL розміщує кожен JOIN на власному рядку і вирівнює предикати WHERE, щоб відсутній AND або зайвий OR помітний з першого погляду.
• Узгодженість стилю команди. Більшість команд приймають керівництво зі стилю SQL (dbt Labs, GitLab, Mode Analytics публікують своє) і хочуть, щоб кожен закомічений запит дотримувався його. Форматер, запущений перед комітом, усуває стильові суперечки з review і залишає лише логіку для обговорення.
• Поширення SQL у документації. Runbook'и, ретроспективи інцидентів і Notion-документи виграють від SQL, який читається зверху вниз. Відформатований SQL акуратно вставляється у блок коду та передбачувано друкується в PDF-експортах, без незручних переносів посередині ключового слова.

Поширені застосування

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

• Аналітична інженерія: pre-commit хук у dbt-проекті, який переформатовує кожен файл моделі, щоб diff pull request залишався в рамках змін логіки, а не пробілів.
• Адміністрування бази даних: вставте однорядковий запис із журналу повільних запитів, відформатуйте його та пройдіться по порядку JOIN під час написання ретроспективи інциденту.
• Документація: візьміть запит із Looker або Tableau, відформатуйте його для runbook і вбудуйте як приклад для копіювання для чергової ротації.

Практичний приклад

Вставте SELECT u.id,u.email,COUNT(o.id) FROM users u LEFT JOIN orders o ON o.user_id=u.id WHERE u.created_at > '2024-01-01' GROUP BY u.id,u.email ORDER BY u.id; у вхідну панель із діалектом PostgreSQL, відступом 2 пробіли та регістром ключових слів ВЕРХНІЙ. Результат розмістить SELECT, FROM, LEFT JOIN, WHERE, GROUP BY та ORDER BY на власних рядках; кожен стовпець у списку select та group-by отримає власний рядок із відступом; предикат ON буде на один відступ глибше ніж ключове слово JOIN.

FAQ

Які SQL-діалекти підтримуються?

Спадний список діалекту охоплює Standard SQL, MySQL, PostgreSQL, SQLite, MariaDB, Transact-SQL (SQL Server / Azure SQL), BigQuery, Snowflake і Redshift. Базова бібліотека sql-formatter також розпізнає DuckDB, Spark SQL, Hive, Trino, Db2, N1QL, PL/SQL, ClickHouse, TiDB та SingleStoreDB — вибір найближчого діалекту дає розумний результат навіть якщо точна ціль не в списку. Ідентифікатори, рядкові літерали та оператори, специфічні для діалекту (PostgreSQL @>, префікси SAFE. BigQuery), зберігаються без змін.

Чи перевіряє це мій SQL?

Ні. Форматер є лексичним переписувачем, а не парсером. Він токенізує введення, застосовує правила компонування та генерує результат; він не перевіряє семантичну коректність запиту, існування таблиць або правильність синтаксису в обраному діалекті. Запустіть відформатований результат через реальну базу даних (або SQL-лінтер як SQLFluff) для реальної перевірки коректності.

Чому мої ключові слова стають у верхньому регістрі?

Спадний список регістру ключових слів за замовчуванням вибирає ВЕРХНІЙ — це прийнята конвенція в більшості опублікованих керівництв зі стилю SQL (dbt Labs, Mode, GitLab). Перейдіть на нижній, якщо ваша команда пише select / from малими літерами, або Зберегти, якщо хочете, щоб результат зберіг будь-який регістр, який ви ввели. Ідентифікатори ніколи не зачіпаються — лише розпізнаний набір ключових слів переписується.

Чи завантажується мій запит будь-куди?

Ні. Вбудована бібліотека sql-formatter запускається у вашому браузері, форматування відбувається локально на вашому комп'ютері, а текст запиту ніколи не перетинає мережу. Єдині вихідні запити, які робить ця сторінка, — ті самі спільні аналітичні та рекламні запити, що й кожна сторінка на tools.ultim8soft.com; текст SQL не є частиною жодного з них.

Відформатований SQL перестає бути стильовою суперечкою, щойно форматер бере на себе цю роботу. Інструмент працює повністю у вашому браузері, запит ніколи не покидає сторінку, а той самий токенайзер з підтримкою діалектів, що живить npm-пакет sql-formatter, виконує перезапис.