Руководство по стилю SQL: рекомендации по форматированию

Руководство по стилю SQL — это набор соглашений, которые делают запросы читаемыми и сохраняют единообразие командных diff-ов. Самому SQL это безразлично: ключевые слова нечувствительны к регистру, а пробельные символы игнорируются, поэтому SELECT, select и SeLeCt выполняются одинаково, и однострочник на 200 символов возвращает ровно те же строки, что и тот же запрос, разнесённый на двадцать строк с отступами. Стиль, таким образом, касается исключительно людей, которые будут читать запрос позже.

Если чистый запрос нужен прямо сейчас, вставьте его в Форматировщик SQL, выберите диалект и скопируйте результат. Но задать командный стандарт, а не спорить о нём в каждом pull request, помогает понимание правил, которые стоят за этим выводом. Дальше разбираю значимые решения: регистр ключевых слов, отступы и переносы строк, именование, особенности отдельных диалектов и то, как всё это автоматизировать.

Прежде чем перейти к деталям, стоит обозначить рамку. Поскольку SQL игнорирует пробелы и регистр, ни одно из этих правил не навязывается базой данных — они существуют ради людей, которые читают, ревьюят и сопровождают запрос. Отсюда два следствия. Во-первых, единственно «правильного» ответа почти никогда нет; большинство решений сводится к выбору разумного соглашения и его повсеместному применению, и где лежат настоящие компромиссы, я говорю прямо, а не делаю вид, что какой-то один стиль побеждает безоговорочно. Во-вторых, раз правила — это соглашения, а не требования, пользу они приносят только при единообразном применении. Поэтому вывод в каждом разделе один: решите один раз, а дальше доверьте контроль инструменту.

Почему форматирование SQL важно

Самый наглядный аргумент в пользу форматирования проявляется на code review. ORM или этап сборки нередко выдаёт запросы одной неразрывной строкой:

select u.id,u.name,count(o.id) as orders from users u left join orders o on o.user_id=u.id where u.active=true group by u.id,u.name order by orders desc

Это невозможно отревьюить. После переформатирования структура становится очевидной, а diff читается построчно:

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Отладка выигрывает точно так же. Когда вы копируете однострочный запрос из лога медленных запросов, а в нём три join-а и запутанный WHERE, форматирование сначала превращает «где же баг» в тридцатисекундный беглый просмотр. Ошибочный предикат оказывается на своей строке, join-ы выстроены друг под другом, и случайное декартово произведение или забытый фильтр внезапно становятся видимыми, а не теряются в сплошной стене текста. Тот же приём помогает, когда вы читаете SQL, сгенерированный какой-то другой системой, — конструкторы запросов и инструменты отчётности часто выдают корректный, но нечитаемый вывод.

Единообразие — выигрыш потише, но со временем самый ценный. Когда все форматируют одинаково, diff-ы показывают только то, что действительно изменилось, — новый столбец, поправленный фильтр, — а не шум от того, что чьи-то предпочтения по расстановке пробелов борются с чужими. Внимание ревьюера конечно; тратить его на перетасованные пробелы — расточительство. Единообразное форматирование также упрощает онбординг: новый сотрудник читает запросы, которые все выглядят одинаково, один раз усваивает форму, принятую в команде, и применяет её везде. Ничего из этого не требует форматировать вручную — это и есть тема последнего раздела: вы задаёте правила, инструмент их применяет.

Один инвариант лежит в основе всего этого, и его стоит проговорить прямо, потому что он повторяется на протяжении всего руководства: форматирование меняет только пробелы, переносы строк, регистр ключевых слов и комментарии. Оно никогда не меняет логику запроса или его результаты. Отформатированный запрос — это тот же самый запрос. Именно поэтому можно безопасно пропустить ту неряшливую версию выше через Форматировщик SQL, не беспокоясь о том, что она вернёт.

Регистр ключевых слов — UPPERCASE против lowercase

Старейший спор в любом руководстве по стилю SQL — должны ли зарезервированные ключевые слова быть UPPERCASE или lowercase. Оба варианта допустимы, потому что для ключевых слов SQL нечувствителен к регистру. Разногласие касается читаемости, и прежде чем выбрать, стоит понять обе стороны.

Доводы за UPPERCASE-ключевые слова

Традиционный аргумент — визуальный контраст. Когда SELECT, FROM, WHERE, JOIN и GROUP BY написаны заглавными, ключевые слова выделяются на фоне имён таблиц и столбцов в нижнем регистре, так что структуру запроса можно охватить взглядом, не полагаясь на подсветку синтаксиса в редакторе.

Это важнее, чем кажется, потому что SQL проходит через множество мест без подсветки синтаксиса: файлы логов, цепочки писем, описания pull request, обычный текстовый diff, сообщение в Slack, дашборд мониторинга, stack trace. Во всех них заглавные ключевые слова — единственное, что удерживает структуру читаемой: уберите подсветку, и select id from users where active превращается в кашу из слов нижнего регистра, тогда как SELECT id FROM users WHERE active по-прежнему с первого взгляда читается как запрос. Это соглашение встречается в большинстве более старых руководств по стилю, в документации баз данных и почти в каждом учебнике по SQL — поэтому многим разработчикам заглавные ключевые слова привычнее, даже когда редактор всё равно их подсветил бы.

Доводы за lowercase-ключевые слова

Современный контраргумент: подсветка синтаксиса решила проблему контраста. Каждый редактор и IDE выделяет ключевые слова отдельным цветом, так что писать их заглавными избыточно — а некоторым читателям ВСЕ ЗАГЛАВНЫЕ кажутся криком. К тому же набирать без shift на каждом ключевом слове чуть быстрее.

У стиля в нижнем регистре есть реальный импульс в мире аналитической инженерии. Сообщество dbt и несколько часто цитируемых командных руководств по стилю по умолчанию используют ключевые слова в нижнем регистре, исходя из логики, что визуальную нагрузку несёт подсветка, а нижний регистр делает запрос спокойнее для чтения. В их пользу есть и более тонкий довод: ключевые слова в нижнем регистре находятся на том же визуальном уровне, что и имена таблиц и столбцов в snake_case, поэтому весь запрос читается как один цельный кусок текста, а не как два регистра — кричащие ключевые слова и тихие идентификаторы, — соперничающие за внимание. Достоинство это или недостаток — ровно тот вопрос, по которому команды расходятся, и здесь полезен один вердикт, который выдерживает критику.

Вердикт — единообразие важнее выбора

Что именно вы выберете, куда менее важно, чем выбрать что-то одно и обеспечить его соблюдение. База кода, где половина запросов кричит SELECT, а другая половина шепчет select, — худший исход, потому что сама несогласованность становится шумом. Смешанный регистр в одном запросе — ещё хуже.

Причина, по которой побеждает единообразие, механическая, а не эстетическая. Несогласованный регистр заставляет diff-ы лгать: ревьюер видит «изменение» строки, которое на самом деле всего лишь чьё-то переформатирование ключевого слова, и настоящая правка прячется среди шума. Grep и поиск тоже становятся менее надёжными, когда одно и то же ключевое слово встречается в трёх вариантах регистра. Единый принудительный стиль снимает все эти издержки ценой одного решения. Так что договоритесь как команда, запишите это и доверьте соблюдение инструменту, а не полагайтесь на дисциплину. В Форматировщике SQL есть элемент управления Keywords с тремя вариантами — UPPERCASE, lowercase и Preserve, — так что можно нормализовать целую гору исторических запросов к одному стилю в один клик. Один и тот же запрос, отрисованный обоими способами:

-- UPPERCASE
SELECT id, email FROM users WHERE active = true ORDER BY created_at DESC;

-- lowercase
select id, email from users where active = true order by created_at desc;

Выберите тот, что предпочитает ваша команда. Суть в том, чтобы ему соответствовали все ваши запросы.

Отступы и переносы строк

Регистр определяет, как выглядят ключевые слова. Отступы и переносы строк определяют, как логика запроса ложится на страницу, и от них читаемость зависит сильнее всего.

Стиль «реки» против блочного стиля

Известный sqlstyle.guide Саймона Холивелла популяризировал стиль «реки», где ключевые слова выровнены по правому краю, так что вертикальный канал из пробелов проходит вниз по середине запроса:

SELECT id,
       email,
       created_at
  FROM users
 WHERE active = true
 ORDER BY created_at DESC;

Привлекательность в том, что SELECT, FROM и WHERE выстраиваются по правому краю, а список столбцов аккуратно располагается справа от «реки». Однако недостатки практические. Выравнивание зависит от длины самого длинного ключевого слова, поэтому добавление LEFT JOIN может вынудить переотступить всё; такое тяжело сопровождать вручную; и это порождает шумные diff-ы, потому что изменение длины одного ключевого слова сдвигает пробелы на соседних строках.

Блочный (или выровненный по левому краю) стиль начинает каждую крупную конструкцию у левого поля на отдельной строке и делает отступ для её содержимого:

SELECT
  id,
  email,
  created_at
FROM users
WHERE active = true
ORDER BY created_at DESC;

Это мейнстримный вариант по умолчанию и тот, что выдаёт большинство инструментов, — именно потому, что он стабилен: добавление конструкции никогда не перекомпоновывает строки выше, поэтому diff-ы остаются небольшими, а раскладка переживает автоматическое форматирование. Стиль «реки» оптимизирован под то, как готовый запрос выглядит в изоляции; блочный стиль оптимизирован под то, как запросы меняются со временем и как они ревьюятся в системе контроля версий. Для всего, что живёт в репозитории и редактируется, блочный стиль — более безопасная ставка, и дальше я исхожу из него.

Сколько пробелов — 2, 4 или табы

Раз уж вы делаете отступ, нужно решить, насколько. У трёх распространённых ответов есть своё обоснование:

• 2 пробела — самый частый вариант по умолчанию. Он сохраняет diff-ы компактными и не даёт вложенным запросам уходить за правый край экрана.
• 4 пробела — дают каждому уровню вложенности больше визуального разделения, что помогает в запросах с глубокими подзапросами или многими уровнями CTE.
• Табы — позволяют каждому разработчику выбрать свою ширину отображения, не меняя файл.

Универсально правильного ответа здесь нет, и именно поэтому Форматировщик SQL предоставляет элемент управления Indent со всеми тремя вариантами (2 spaces, 4 spaces, Tab). Выберите один и применяйте его везде.

Где переносить строки

Ширина отступа — лёгкая часть. Более значимое решение — где вставлять переносы строк:

• Столбцы SELECT — по одному столбцу на строку для всего нетривиального, чтобы добавление или удаление столбца затрагивало в diff-е ровно одну строку. Очень короткие запросы могут оставаться на одной строке.
• FROM и JOIN — начинайте каждый join на своей строке, а условие ON либо в хвосте, либо с отступом под ним. Это сохраняет граф соединений читаемым.
• WHERE — помещайте каждый AND / OR на отдельную строку, чтобы булева логика читалась сверху вниз. Для смешанных условий AND/OR заключайте группы в скобки и делайте отступ, чтобы приоритет был явным, а не тем, что читателю приходится вычислять.

Это рекомендации, а не законы. Тривиальный SELECT id FROM users WHERE id = 1 не нуждается в пяти строках, и навязывание ему их вредит читаемости, а не помогает. Оценочное суждение примерно такое: переносить, когда в запросе больше одного-двух столбцов, больше одной таблицы или больше одного условия. Ниже этого порога одна строка яснее; выше — переносите агрессивно. Хороший форматировщик закладывает разумный порог за вас, но принцип стоит понимать, чтобы вывод никогда вас не удивлял.

Применённые к неряшливому однострочнику из начала, эти правила дают раскладку, где каждая конструкция и каждый join видны с первого взгляда:

SELECT
  u.id,
  u.name,
  COUNT(o.id) AS orders
FROM users u
LEFT JOIN orders o ON o.user_id = u.id
WHERE u.active = true
GROUP BY u.id, u.name
ORDER BY orders DESC;

Запятые в начале против запятых в конце

Вопрос помельче, но устойчивый: куда ставить запятую в многострочном списке столбцов?

-- Leading commas
SELECT
    id
  , email
  , created_at
FROM users;

-- Trailing commas
SELECT
    id,
    email,
    created_at
FROM users;

У запятых в начале есть настоящее преимущество: добавление или удаление столбца меняет одну строку, а пропущенную запятую легко заметить, потому что провинившаяся строка бросается в глаза. Запятые в конце читаются естественнее и на практике встречаются гораздо чаще. Оба варианта хороши — выберите один и доверьте форматировщику его применять, чтобы об этом больше не приходилось думать.

Соглашения об именовании таблиц и столбцов

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

Де-факто стандарт для идентификаторов SQL — snake_case — всё в нижнем регистре, слова разделены подчёркиваниями: user_id, created_at, order_items. Этот статус он заслужил по конкретной причине, а не просто по привычке: идентификаторы в snake_case никогда не требуют кавычек и ведут себя согласованно во всех диалектах, тогда как camelCase (привычный в коде приложений) конфликтует с тем, как базы данных сворачивают регистр, к чему мы вскоре перейдём.

Стоит явно проговорить, почему это отличается от кода приложения. В большинстве языков программирования идентификаторами управляет окружающий код, и нормой служит camelCase или PascalCase. Идентификаторы SQL, напротив, интерпретируются собственными правилами свёртки регистра базы данных, и именно эти правила делают имена в смешанном регистре хрупкими. snake_case обходит проблему целиком: сворачивать нечего, ставить кавычки незачем, и от движка к движку поведение не меняется.

Ещё несколько соглашений, которые встречаются почти в каждом руководстве по стилю SQL:

• Единственное число против множественного в именах таблиц — настоящий раскол. users (множественное, «таблица содержит пользователей») и user (единственное, «каждая строка — это пользователь») оба имеют сторонников. Как и с регистром, выбор важен меньше, чем его согласованное применение к каждой таблице.
• Избегайте зарезервированных слов в качестве идентификаторов. Назвав столбец order, user или table, вы вынуждаете себя ставить кавычки повсюду и напрашиваетесь на сбивающие с толку ошибки. Берите вместо этого order_id или account.
• Сохраняйте единообразие в именовании ключей. Первичный ключ под названием id и внешние ключи вида <referenced_table>_id (например, user_id) делают join-ы предсказуемыми и самодокументируемыми.

Есть одна ловушка, которую стоит назвать явно, потому что она кусает команды, называющие столбцы базы данных так же, как переменные приложения. В PostgreSQL некавыченный идентификатор сворачивается в нижний регистр, поэтому SELECT userId FROM t на самом деле ищет столбец с именем userid. Как только вы возьмёте его в кавычки — "userId" — база данных сохраняет регистр и трактует "userId" и userid как два разных столбца:

-- Создаёт столбец, чьё настоящее имя — в нижнем регистре "userid"
CREATE TABLE t (userId integer);

-- Оба этих запроса работают — имя было свёрнуто в нижний регистр
SELECT userId FROM t;
SELECT userid FROM t;

-- Это завершается ошибкой: "column \"userId\" does not exist"
-- Кавычки требуют точного, чувствительного к регистру совпадения
SELECT "userId" FROM t;

Учтите, что разные базы данных сворачивают регистр в разные стороны — Oracle сворачивает некавыченные идентификаторы в верхний регистр, ряд других — в нижний, — так что кавыченные идентификаторы в смешанном регистре даже не переносимы. Чистый выход — вовсе избегать кавыченных идентификаторов в смешанном регистре и держаться snake_case, что обходит всю проблему стороной и сохраняет вашу схему читаемой в любом диалекте.

Более глубокое сравнение camelCase, snake_case и kebab-case — включая то, когда каждый из них уместен в коде и данных, — смотрите в руководстве по соглашениям об именовании.

Форматирование в разных диалектах SQL

Всё сказанное выше по большей части не зависит от диалекта — регистр, отступы, переносы строк и именование применимы независимо от того, на какую базу данных вы нацелены. Но «отформатируй этот SQL» упирается в стену в тот момент, когда запрос использует синтаксис, специфичный для одной базы данных, потому что универсальный парсер, который этот синтаксис не распознаёт, его искалечит: он может разбить токен не в том месте, неверно прочитать оператор или принять символ кавычек за разделитель строки и проглотить половину запроса. Тут и оправдывает себя форматирование с учётом диалекта, и поэтому форматировщик просит вас сначала выбрать базу данных, а не угадывает. Различия ниже — те, с которыми вы сталкиваетесь чаще всего в повседневных запросах.

Операция	PostgreSQL	MySQL / MariaDB	SQL Server (T-SQL)	Oracle	Standard SQL
Конкатенация строк	|| или CONCAT()	CONCAT()	+ или CONCAT()	|| или CONCAT()	||
Обработка NULL	COALESCE()	COALESCE() / IFNULL()	COALESCE() / ISNULL()	COALESCE() / NVL()	COALESCE()
Ограничение строк	LIMIT	LIMIT	TOP / OFFSET … FETCH	FETCH FIRST	FETCH FIRST
Экранирование идентификаторов	двойные кавычки ("…")	обратные кавычки	квадратные скобки ([…])	двойные кавычки ("…")	двойные кавычки ("…")

Конкатенация строк и обработка NULL

Две самые распространённые повседневные операции записываются по-разному в разных диалектах.

Конкатенация строк:

-- PostgreSQL, Oracle, SQLite (standard operator)
SELECT first_name || ' ' || last_name AS full_name FROM users;

-- SQL Server (T-SQL uses +)
SELECT first_name + ' ' + last_name AS full_name FROM users;

-- Portable across dialects
SELECT CONCAT(first_name, ' ', last_name) AS full_name FROM users;

Запасные значения для NULL:

-- Standard SQL (works everywhere)
SELECT COALESCE(nickname, name) AS display_name FROM users;

-- SQL Server only
SELECT ISNULL(nickname, name) AS display_name FROM users;

-- MySQL / MariaDB only
SELECT IFNULL(nickname, name) AS display_name FROM users;

Форматировщик, настроенный на неверный диалект, может не понять ISNULL или оператор || и неправильно разобрать окружающий запрос.

Ограничение строк и кавычки в идентификаторах

Ограничение числа строк результата — один из самых расходящихся по диалектам кусков синтаксиса:

-- PostgreSQL, MySQL, SQLite
SELECT id, name FROM users ORDER BY created_at DESC LIMIT 10;

-- SQL Server (T-SQL)
SELECT TOP 10 id, name FROM users ORDER BY created_at DESC;

-- Standard SQL / Oracle
SELECT id, name FROM users ORDER BY created_at DESC FETCH FIRST 10 ROWS ONLY;

Кавычки в идентификаторах тоже расходятся на три варианта. Когда идентификатор приходится брать в кавычки — обычно чтобы использовать зарезервированное слово или сохранить регистр, — разделитель зависит от базы данных:

-- MySQL / MariaDB use backticks
SELECT `order`, `user` FROM `select`;

-- SQL Server (T-SQL) uses square brackets
SELECT [order], [user] FROM [select];

-- Standard SQL (PostgreSQL, Oracle, SQLite) uses double quotes
SELECT "order", "user" FROM "select";

Форматировщик, который считает бэктики MySQL разделителями строк или скобки T-SQL чем-то иным, выдаст сломанный вывод. Именно настройка диалекта подсказывает ему, что есть что. Это и причина, по которой копирование запроса между базами данных редко бывает чистой заменой: одно и то же логическое намерение — соединить две строки, откатиться к NULL, ограничить десятью строками, взять зарезервированное слово в кавычки — записывается четырьмя разными способами в разных диалектах, и только парсер, знающий вашу базу данных, может переформатировать его, не испортив.

Почему форматирование с учётом диалекта важно

Именно поэтому Форматировщик SQL поставляется с девятью диалектами — PostgreSQL, MySQL, SQL Server (T-SQL), BigQuery, Snowflake, Oracle, SQLite, MariaDB и Standard SQL, — а не с единым универсальным режимом. Выбор правильного означает, что парсер корректно обрабатывает строки в долларовых кавычках PostgreSQL и приведения ::, идентификаторы в скобках T-SQL и TOP, специфичные для хранилищ функции в BigQuery и Snowflake, а также правила кавычек выше, вместо того чтобы гадать и ошибаться. Выберите вашу реальную базу данных из выпадающего списка перед форматированием — и вывод вернётся корректным и идиоматичным.

Автоматизация форматирования SQL

Прочитать правила — полдела; применять их вручную не должен никто. Смысл руководства по стилю в том, что его соблюдение обеспечивает машина. Встроить форматирование можно в трёх местах — выбор зависит от того, сколько трения вы хотите убрать.

В редакторе (форматирование при сохранении)

Вариант с наименьшими усилиями — форматировать автоматически при каждом сохранении. У VS Code есть расширения-форматировщики SQL, работающие при сохранении, а JetBrains DataGrip и инструменты для баз данных в других IDE поставляются со встроенным форматировщиком, который можно привязать к сочетанию клавиш или хуку сохранения. Раз настроив, вы получаете запросы, которые попросту никогда не бывают неотформатированными, — та же модель, что Prettier для JavaScript или gofmt для Go. Загвоздка в том, что настройки редактора живут на машине каждого разработчика, поэтому форматирование при сохранении держит в порядке ваш SQL, но само по себе не гарантирует, что то же делает остальная команда. Для этого нужен следующий слой.

В CI с линтером

Чтобы обеспечить стиль во всей команде, перенесите проверку в непрерывную интеграцию. Линтер SQL вроде sqlfluff и линтит, и автоматически исправляет: вы кодируете свои правила — диалект, регистр ключевых слов, отступы, расстановку запятых — в конфигурационном файле .sqlfluff, запускаете sqlfluff lint, чтобы пометить нарушения, и sqlfluff fix, чтобы их устранить, и заставляете CI отклонять любой pull request, отклонившийся от согласованного стиля. Это та же идея, что ESLint или Prettier, контролирующие фронтенд-репозиторий: стиль перестаёт быть комментарием на ревью, который кто-то должен не забыть оставить, и становится проходящей или падающей проверкой, о которой машина никогда не забывает. Выигрыш в том, что споры о стиле случаются один раз, когда вы пишете конфиг, а не в каждом pull request.

Разовое онлайн-форматирование

Иногда у вас просто есть один уродливый запрос и никакого желания что-либо устанавливать — фрагмент из лога, сообщение коллеги в Slack, запрос, который вы вставляете в документацию. Для этого вставьте его в Форматировщик SQL, выберите диалект, регистр и отступы и скопируйте чистый результат.

Деталь про приватность здесь важна, и её легко упустить. Многие онлайн-форматировщики отправляют вставленный вами текст на сервер, чтобы выполнить работу, а значит, копия вашего запроса — имена таблиц, имена столбцов, иногда литеральные значения из продакшен-инцидента — покидает вашу машину. Форматировщик SQL работает целиком в вашем браузере, поэтому ваш SQL никогда никуда не загружается. Это делает безопасным форматирование запросов, которые затрагивают продакшен-схемы или проприетарную логику, — а это ровно та ситуация, где чистое форматирование нужно больше всего, а отдавать свой запрос третьей стороне хочется меньше всего. Если в том же рабочем процессе вы возитесь с другими форматами, родственный Форматировщик JSON работает так же — та же обработка в браузере, то же копирование в один клик.

Три подхода не взаимоисключающие, и обычно их сочетают: форматирование при сохранении для быстрого внутреннего цикла, пока вы пишете, линтер в CI как страховка, обеспечивающая командный стандарт, и онлайн-форматировщик для одноразовых фрагментов, которые никогда не попадают в репозиторий. Ни один из этих инструментов не меняет того, что делает ваш запрос: они переставляют пробелы, переносы строк, регистр и комментарии — и ничего больше.

Часто задаваемые вопросы

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

Оба варианта допустимы, потому что ключевые слова SQL нечувствительны к регистру. UPPERCASE выделяет ключевые слова в средах без подсветки синтаксиса, таких как логи и diff-ы; lowercase легче набирать и он вписывается в современные редакторы, которые и так раскрашивают ключевые слова. Что действительно важно — чтобы вся команда выбрала что-то одно, а форматировщик обеспечивал соблюдение; смешанный регистр — худший выбор.

Какой отступ лучше для SQL?

Два пробела — самый частый вариант по умолчанию, он сохраняет diff-ы компактными; четыре пробела облегчают чтение глубоко вложенных запросов; табы позволяют каждому разработчику выбрать свою ширину отображения. Единственно правильного ответа нет — выберите один и применяйте его согласованно во всей команде. Большинство форматировщиков SQL, включая этот, поддерживают все три варианта.

Как форматировать SQL автоматически?

Есть три способа форматировать SQL автоматически: форматирование при сохранении в редакторе (VS Code или DataGrip), линтер в CI вроде sqlfluff, который автоматически исправляет стиль, или онлайн-форматировщик SQL для разовой вставки. Онлайн-путь самый быстрый, потому что не требует установки — просто вставьте, выберите диалект и скопируйте результат.

Использовать запятые в начале или в конце строки в SQL?

Запятые в начале (запятая в начале каждой строки) дают более чистые diff-ы при добавлении или удалении столбцов и облегчают обнаружение пропущенной запятой; запятые в конце (запятая в конце) читаются естественнее и встречаются чаще. Оба варианта приемлемы в любом руководстве по стилю SQL — главное выбрать один и доверить форматировщику применять его автоматически.

Меняет ли форматирование SQL то, как выполняется запрос?

Нет. Форматирование SQL меняет только пробелы, переносы строк, регистр ключевых слов и комментарии — оно никогда не меняет логику запроса. Отформатированный запрос возвращает ровно те же результаты, что и исходный, поэтому совершенно безопасно приводить в порядок даже продакшен-запросы перед ревью или выполнением.

Какое соглашение об именовании использовать для таблиц и столбцов SQL?

snake_case — всё в нижнем регистре с подчёркиваниями — это де-факто стандарт для имён таблиц и столбцов SQL, потому что он избегает кавычек и остаётся безопасным во всех диалектах. Держите первичные ключи (id) и внешние ключи (user_id) названными единообразно и избегайте использования зарезервированных слов вроде order или user в качестве идентификаторов, чтобы не наживать проблем с кавычками.

Как форматировать SQL под конкретный диалект вроде PostgreSQL или T-SQL?

Сначала выберите подходящий диалект в форматировщике. Режим PostgreSQL корректно обрабатывает приведения :: и строки в долларовых кавычках; режим SQL Server (T-SQL) понимает идентификаторы в скобках [identifiers] и TOP. Выбор неверного диалекта позволяет универсальному парсеру искалечить специфичный для диалекта синтаксис, поэтому всегда устанавливайте его в вашу реальную базу данных перед форматированием.

Существует ли стандартное руководство по стилю SQL?

Официального стандарта нет, но есть несколько широко упоминаемых: sqlstyle.guide Саймона Холивелла и публичные руководства по стилю от команд вроде Mozilla и сообщества dbt. Их общий консенсус — согласованные отступы, идентификаторы в snake_case и перенос строки перед каждой крупной конструкцией — это то, что кодифицирует данное руководство, и форматировщик может обеспечить его соблюдение за вас.