Почему важен выбор диалекта
SQL — стандарт примерно в той же степени, в какой стандартом является английская орфография. Каждая СУБД реализует общее ядро, а затем добавляет синтаксис, которого нет ни у кого другого, и средство форматирования, не знающее вашу целевую СУБД, либо разберёт этот синтаксис неверно, либо молча пропустит его без форматирования.
Различия вовсе не экзотические. Одно только цитирование идентификаторов делит поле: MySQL использует обратные кавычки, PostgreSQL и стандартный SQL — двойные кавычки, а SQL Server — квадратные скобки. Средство форматирования, предполагающее неверное соглашение, может принять идентификатор в кавычках за строковый литерал и перестроить запрос по несуществующей границе. Помимо кавычек есть LIMIT против TOP против FETCH FIRST, оператор приведения типов :: в PostgreSQL, переменные T-SQL с префиксом @, пути проектов BigQuery в обратных кавычках и предложение QUALIFY в Snowflake. Именно выбор правильного диалекта сохраняет всё это в целости.
Отступы — это решение о диффах
Размер отступа и регистр ключевых слов кажутся косметикой, но именно они определяют, как будет выглядеть история вашей системы контроля версий. Форматирование полезно только тогда, когда оно единообразно, потому что стоит двум людям отформатировать один файл по-разному, и каждый коммит начинает нести волну не связанных с делом изменений пробелов, а код-ревью перестаёт работать. Выберите одну конфигурацию, запишите её в репозиторий и применяйте механически.
Прописные ключевые слова — самое распространённое соглашение, и они помогают при чтении плотного запроса, поскольку структурные слова визуально отделяются от имён таблиц и столбцов. Строчные набирают популярность в кодовых базах, где SQL воспринимают как обычный код и не любят «крик». «Сохранить» — верный выбор, когда вы форматируете чужой запрос и хотите изменить только раскладку, не тронув ни одного символа текста: тогда получившийся дифф будет чисто структурным.
У спора о табуляциях и пробелах есть обычные аргументы и одна особенность, связанная с SQL: запросы часто вставляют в терминалы, системы тикетов и чат-клиенты, где табуляция отображается как восемь колонок. Глубоко вложенный запрос с отступами табуляцией может переноситься до неузнаваемости именно там, где вы, скорее всего, будете им делиться.
Чего форматирование не сделает
Форматирование — исключительно вопрос представления. Оно не ускорит запрос и ничего не изменит в плане, который построит оптимизатор. Красиво оформленный коррелированный подзапрос всё равно выполняется для каждой строки. Для работы над производительностью используйте EXPLAIN, а средство форматирования — для читаемости.
Оно также не выполняет проверку. Этот инструмент разбирает запрос достаточно, чтобы переформатировать текст, но он не является парсером СУБД и с удовольствием отформатирует запрос с опечаткой в имени столбца или пропущенным условием соединения. Аккуратный формат — не проверка синтаксиса, и единственный авторитет в вопросе корректности запроса — та база данных, в которой вы собираетесь его выполнять.
Единственная привычка, которую стоит освоить вместе с форматированием, — параметризация. Форматирование запроса со значениями, склеенными в строку, делает риск инъекции более наглядным, но не менее реальным. Если вы форматируете SQL, в который пользовательский ввод вставлен прямо в текст, то первым делом стоит исправлять не форматирование.