Форматтер SQL

Форматтер, который делает ключевые слова заглавными, сопоставляя целые слова регулярным выражением, не способен понять, является ли конкретное вхождение «order» ключевым словом SQL `ORDER` (как в `ORDER BY`) или литеральным строковым значением, которое просто содержит это слово, — запрос, фильтрующий строки через `WHERE description = 'the order from stock'`, содержит слово «order» внутри строки в кавычках, вообще не выступая ключевым словом. Наивный форматтер делает заглавным каждое совпавшее слово вне зависимости от контекста, искажая литеральное строковое значение в 'the ORDER FROM stock' и незаметно меняя то, что запрос на самом деле фильтрует. Правильная токенизация запроса — распознавание границ строк в кавычках до того, как решается, что считается ключевым словом, — как раз и предотвращает это, и это ровно тот класс ошибок, который проявляется только на реальных данных, содержащих слова, случайно совпадающие с ключевыми словами SQL, поэтому его легко пропустить при тестировании на простых примерах запросов.

Этот инструмент распознаёт общую структуру разделов, разделяемую PostgreSQL, MySQL, SQL Server, SQLite и Oracle — SELECT, FROM, WHERE, JOIN, GROUP BY, ORDER BY и им подобные, — достаточно хорошо, чтобы расставить каждый раздел на своей строке и правильно вложить подзапросы. Он не строит полное понимание грамматики какой-либо конкретной базы данных целиком, включая специфичные для конкретного производителя расширения — например, синтаксис массивов PostgreSQL или расположение оператора `TOP` в SQL Server. На практике это означает, что специфичный для диалекта синтаксис проходит через форматтер без изменений вместо того, чтобы вызвать ошибку, но и не получает такого же аккуратного отступа, как общие разделы, — разумный компромисс ради поддержки пяти диалектов одним форматтером вместо отдельного инструмента для каждой СУБД.

Ключевые слова SQL нечувствительны к регистру по самой спецификации языка — `SELECT`, `Select` и `select` идентичны для любого SQL-движка, — и именно поэтому капитализация или декапитализация является чисто косметической операцией без какого-либо риска изменить поведение. То же самое верно для пробелов и переносов строк, которые добавляет этот форматтер: запрос, растянутый на двенадцать строк с отступами, выполняется точно так же, как тот же запрос, впихнутый в одну строку. Форматирование никак не затрагивает те токены, которые определяют, какие таблицы читаются, какие условия фильтруют строки или какие значения вставляются, — оно влияет только на то, как эта же логическая структура запроса визуально представлена человеку, читающему его впоследствии.

Запрос, сгенерированный ORM, экспортированный из графического интерфейса базы данных или написанный одной разрастающейся строкой в спешке во время миграции, часто функционально корректен, но по-настоящему трудно читается человеком в исходном виде — запрос с пятнадцатью джойнами без переносов строк затрудняет понимание того, какому джойну принадлежит какое условие, и правильную ли таблицу фильтрует WHERE. Переформатирование его так, чтобы каждый раздел и каждый джойн находились на своей строке с отступом, отражающим реальную структуру запроса, зачастую оказывается самым быстрым способом действительно понять, что делает длинный сгенерированный запрос, перед тем как одобрить его в код-ревью или разобраться, почему он возвращает не те строки.