Форматирование/улучшение 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 нет конфиденциальных литералов. Перед отправкой текста на сервер проверь как однострочные, так и блочные комментарии.

Ключевые слова SQL лучше писать в верхнем или нижнем регистре?

Обычно допустимы оба варианта, поскольку многие СУБД не учитывают регистр ключевых слов без кавычек. Следуй соглашениям, принятым в репозитории, и будь внимателен с идентификаторами в кавычках: некоторые базы данных сохраняют или различают их регистр.

Что проверить перед запуском отформатированного запроса?

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