SQL стандартизирован с 1987 года и поддерживается в прежнем виде ИСО/МЭК 9075хотя каждый движок добавляет сверху свой собственный диалект - именно поэтому форматировщику приходится анализировать, а не сопоставлять шаблоны.
Худший запрос, который мне когда-либо приходилось пересматривать, — это 340 строк на одной логической мысли: отчет о доходах для Laravel SaaS, написанный как одна DB::select() Сырая строка, созданная за восемь месяцев тремя разработчиками, у каждого из которых было свое представление о капитализации, и ни о чем не обрывы строк. где-то на этой стене текста LEFT JOIN тихо стал INNER JOIN во время рефактора, и клиенты с нулевым заказом исчезли из отчета Ошибка была одно слово Найти его потребовалось полтора дня - не потому, что логика была жесткой, а потому, что запрос был нечитаемый, а нечитаемый код скрывает свои ошибки на виду.
Вот что касается SQL: база данных не заботится о вашем форматировании. парсер читает select id,name from users where active=1 а SELECT id, name FROM users WHERE active = 1 как тот же оператор, производит тот же план выполнения, возвращает те же строки в то же время Форматирование SQL чисто для людей - именно поэтому это 's стоит сделать, потому что люди - это те, кто просматривает его, отлаживает его в 2 часа ночи, и наследует его через три задания Запрос, который вы можете 't skim - это запрос, который вы можете 't проверить.
выше Форматтер SQL превращает любой запрос - вставленный из журнала, ORM's отладочный вывод, coworker's Slack сообщение, устаревший хранимый порядок - в последовательно отступы, последовательно в оболочке, обзорный SQL в один клик. тот, что на Toolz.dev полностью работает в вашем браузере, что имеет большее значение для SQL, чем для почти любого другого текста вы'd вставить в онлайн инструмент, потому что производственные запросы несут вашу схему, а иногда и ваши данные.
В этом руководстве рассматриваются, как его использовать, правила форматирования, которые на самом деле имеют значение (корпус ключевых слов, отступ и война запятой) и рабочие процессы, в которых форматтер ежедневно оплачивает себя.
TL;DR: Вставьте любой запрос в Toolz.dev SQL форматтер и вернитесь последовательно с отступом, SQL в ключевом слове - мгновенно, бесплатно, на стороне клиента, без регистрации. Форматирование никогда не меняет того, что делает запрос и как быстро он выполняется; это меняет, может ли человек его проверить. Соглашения, которые стоит принять: ключевые слова в верхнем регистре, по одному предложению в строке, отступ под каждым предложением, выберите стиль запятой и перестаньте спорить об этом. Соедините его с Форматтер JSON Для уровня API над вашей базой данных и Инструмент текстового дифференциала Для сравнения двух версий запроса.
Основные характеристики
Один клик постоянный отступ
Основной ход форматировщика и #39;s: каждое основное предложение - SELECT, FROM, WHERE, GROUP BY, ORDER BY - начинает свою собственную строку с столбцами, условиями и соединениями с отступом внизу. Это & quot;river" структура, которую испытали считыватели SQL, сканируют по: глаз бежит вниз по левому краю, читая ключевые слова предложения, затем погружается в любое предложение. 60-строчный форматированный запрос с четкой структурой обзоров более энергичный чем 6-строчный неформатный, потому что структура делает половину чтения для вас.Моя 340-строчная страшилка была бы двадцатиминутным обзором с такой формой - измененный тип соединения сидел бы один на своей линии, явно неправильно.
Нормализация ключевых слов
SELECT против select действительно, это не имеет значения ' имеет значение для любой базы данных - ключевые слова SQL нечувствительны к регистру в соответствии со стандартом, и каждый диалект уважает это. Однако для кодовой базы это имеет огромное значение, поскольку смешанная оболочка - это визуальный шум, который делает структурно идентичные запросы разными. Ключевые слова в верхнем регистре - это старое соглашение, датируемое редакторами без подсветки синтаксиса, где SELECT в заглавной букве был подсветка. Я по-прежнему пишу заглавные буквы - ключевые слова появляются в строчных идентификаторах, и он сохраняет каждый контекст, который выделяет полосы: журналы, различия, электронная почта в открытом виде, вывод терминала. Форматировщик нормализуется к выбранному вами соглашению, поэтому кодовая база, написанная пятью людьми, читается так, как будто она была написана одним.
Обрабатывает вывод ORM и журнала
Наиболее нуждающиеся в форматировании запросы не писали: красноречивый и активный Record вывод, сгенерированные присоединения Doctrine, монстры в вашем журнале медленного запроса. Вывод ORM поступает в виде одной строки с псевдонимами, сгенерированными машиной (t0, t1, laravel_reserved_0), и чтение его сырой это как вы получаете головные боли Мое единственное наиболее частое использование форматировщика: захватить запрос от Laravel's запросить журнал или Телескоп, отформатировать его, и на самом деле увидеть, что ORM решил сделать - что является первым шагом каждого & quot; почему эта конечная точка медленный" расследование, прямо перед EXPLAIN, йо-
Многодиалектная толерантность
Реальный SQL — это семейство диалектов: идентификаторы MySQL, цитируемые по очереди, двойные кавычки PostgreSQL и :: Приведения, квадратные скобки SQL Server и TOP, SQLite все легко. Полезный форматтер обрабатывает их все, не требуя, чтобы вы сначала объявили диалект, сохраняя синтаксис для конкретного диалекта, а не «исправляя его». Стандарт ANSI/ISO SQL (ISO/IEC 9075) определяет общее ядро, но никто не пишет чисто стандартный SQL на практике, и форматтер, который только говорит, что стандарт, будет захлебываться при первой обратке.
Сохраняет семантика, гарантировано
Стоит заявить явно, потому что это & #39;s страх, который останавливает людей: форматирование не может изменить результаты. Пробел и случай ключевых слов не семантичны в SQL - единственное историческое предостережение заключается в следующем Струнные литералы Сравниваются с учетом регистра или нет в зависимости от вашей сопоставления, и форматтер никогда не касается внутренней части ваших цитируемых строк. Вывод тот же оператор, байт за байт, где имеют значение байты. EXPLAIN На обеих версиях, если хотите увидеть: идентичные планы.
Клиентская, что на самом деле здесь важно
SQL - это наиболее чувствительная текстовая категория, которая обычно вставляется в онлайн-инструменты. Запросы раскрывают вашу схему - имена таблиц, имена столбцов, отношения - и запросы, скопированные из журналов, часто содержат буквальные значения: электронные письма WHERE Предложения, диапазоны ID, иногда что-то, что никогда не должно было быть в строке запроса. выше Toolz.dev Форматтер обрабатывает все в вашем браузере; ничего не передается. для SQL конкретно, I'd вызвать клиентскую обработку требование, а не функцию - проверить это на вкладке Сеть и затем расслабиться.
Как использовать форматтер SQL
Шаг 1: Захватите запрос
Скопируйте SQL из источника: ваш файл миграции, хранимую процедуру, вывод отладки ORM (DB::listen() или телескоп в Ларавель, ActiveRecord::Base.logger в Rails), журнал медленного запроса или вкладка запроса вашего инструмента APM. Если он произошел из журнала, он мог избежать кавычек или заполнителей параметров (?, $1) - это 's хорошо, форматировщики обрабатывают заполнители, и часто важно видеть их ясно.
Шаг 2: Вставка и формат
откройте Форматтер SQL, вставить, и форматированная версия появляется. Нет диалектной церемонии, нет конфигурации, необходимой для получения хорошего по умолчанию. если ваш запрос включает несколько операторов, разделенных точкой с запятой, они форматируются как отдельные операторы - полезны для чтения сценариев миграции целиком.
Шаг 3: Прочитайте это как рецензент
Теперь сделайте то, что форматирование существует для: Сканировать левый край. С какими таблицами соединены и с какими типами объединения? Делает ли WHERE у пункта есть условия, которые вы ожидаете - и есть AND/OR Группировки в скобках так, как вы думать они группируются? (приоритет оператора в SQL PUTS AND перед OR, и непарентизированные миксы двух являются вторым по величине источником ошибки, который я вижу в обзоре, сразу после неправильных типов объединения.) Форматированный SQL делает обе ошибки видимыми за секунды.
Шаг 4: Скопируйте его обратно - выборочно
Для запросов, запущенных в вашу кодовую базу, скопируйте отформатированную версию в миграцию, ->select() Сырое выражение, .sql пилка Для разовой отладки не заморачивайте круглые пути; форматированная копия послужила своей цели в тот момент, когда вы ее прочитали. одно место не Чтобы вставить форматированный SQL: в системы, в которых хранятся запросы в виде строк конфигурации, где чьи-либо инструменты diff теперь будут отображать стену изменений пробелов. Формат для чтения всегда; переформатируйте сохраненные запросы только тогда, когда вы готовы владеть diff.
Шаг 5: Стандартизируйте командную конвенцию
Форматировщик и #39; Самая большая ценность - это усложнение: выберите соглашения, которые вы можете автоматизировать - регистр ключевых слов и ширина отступов - это два, которые этот форматировщик контролирует напрямую - форматируйте все новое на пути к кодовой базе, и трение обзора SQL навсегда прекращается. Запишите выбор в своем руководстве по участию. Выбранное конкретное соглашение имеет гораздо меньшее значение, чем все, кто использует одно и то же - предложение, которое справедливо для всех дебатов о форматировании в программном обеспечении и которому примерно никто не верит в середине дебатов.
Техническое глубокое погружение: съезды, которые стоит иметь мнения о
Корпус с ключевыми словами. Ключевые слова в верхнем регистре, идентификаторы в нижнем регистре - доминирующее соглашение и моя рекомендация. Аргумент - это 't традиция - it's надежность. Подсветка синтаксиса исчезает в журналах, терминалах, комментариях к обзору кода, а ответы о переполнении стека вставляются в Slack; Ключевые слова в верхнем регистре подчеркивают, что путешествует с текстом. Контраргумент (все в нижнем регистре, пусть редактор выделит) связный, и I' работал в кодовых базах, которые использовали его с удовольствием. Что и#39; не связно - это смешивание, что и получается без форматировщика, обеспечивающего выбор.
Один пункт в строке, содержимое с отступом. Структурное правило с наивысшими выплатами. SELECT Начинает строку; ее столбцы имеют отступы ниже (или на той же строке, если короткая). каждый JOIN получает свою линию со своим ON видимое состояние - условия соединения скрыты в середине линии, где скрываются ошибки неправильного соединения. WHERE Условия складываются по одной строке, выровнены, с AND/OR Ведущие каждую строку, чтобы логическая структура читалась вертикально. Когда условия запроса, читаемые как столбец, отсутствующее условие отображается как пробел в выкройке, какие человеческие глаза исключительно хорошо ловят.
Запятая война. Конечные запятые (после каждого столбца) читаются естественным образом; ведущие запятые (перед каждым столбцом, при старте линии) делают пунктуацию структурной:
-- Trailing (most common)
SELECT
u.id,
u.email,
o.total
-- Leading (the DBA classic)
SELECT
u.id
, u.email
, o.total
У сторонников ведущей запятой есть два действительно хороших момента: комментировать любую строку, кроме первой, никогда не прерывает утверждение, а в левом поле мгновенно видна отсутствующая запятая. У сторонников задней запятой есть один: он похож на любой другой язык, который вы пишете. Я пишу конечные запятые и перестал чувствовать себя плохо из-за этого, но обратите внимание, что SQL, в отличие от современных JavaScript или Python, так и есть не простите висящую запятую после финального столбца, поэтому эта дискуссия вообще существует и почему ведущий стиль отказывается умирать в кругах DBA. Полное раскрытие: форматировщик Toolz.dev принимает основную сторону и выдает конечные запятые - у него нет режима ведущей запятой, так что если вы 'ре преданный магазин ведущей запятой это единственное соглашение, которое он выиграл 't переформатировать для вас.Выберите домашний стиль, применяйте его последовательно и двигайтесь дальше.
Что форматирование не делает. Он не оптимизирует. отформатированный SELECT * В пятистолбц-соединении есть красивая проблема с производительностью. Форматирование - это предварительный для оптимизации - вы не можете рассуждать о запросе, который вы не можете прочитать - но рассуждения все равно требуют EXPLAIN, индексировать осведомленность и знать форму ваших данных. Я думаю о конвейере как: формат, читай, EXPLAIN, затем оптимизировать. Пропуск шага один не делает вас быстрее, он делает шаги с второго по четвертый медленнее. Та же дисциплина применяется к API, что касается API, поэтому Руководство по форматированию JSON приводит структурно идентичный аргумент о полезной нагрузке.
Комментарии выживают. В отличие от минификации форматирование сохраняет комментарии - -- Линейные комментарии и /* */ Блоки проходят целыми. Используйте их. равняется -- deliberately LEFT JOIN: include customers with no orders Комментарий выше Присоединение — это самая дешевая страховка от ошибок, когда-либо написанная, и это комментарий, необходимый моей 340-строчной истории ужасов.
Общие варианты использования
Обзор кода
Неформатированный SQL в запросе на вытягивание - это обзор, который произойдет 't - глаза рецензента и #39;s соскальзывают со стены текста, и одобрение все равно приземляется. Форматирование запроса перед открытием PR - это основная вежливость с измеримой выгодой: типы соединений, группы условий и списки столбцов становятся видимыми индивидуально, а это означает, что они становятся доступными для индивидуальной проверки. Каждая настоящая ошибка SQL I' попало в обзор - неправильное соединение, не в скобках OR, DELETE отсутствует половина WHERE предложение - я поймал, потому что запрос был отформатирован достаточно хорошо, чтобы читать строка за строкой.
Отладка запросов, созданных ORM
ORM замечательны вплоть до тех пор, пока конечная точка не станет медленной, после чего вам нужно увидеть фактический SQL - и выход ORM всегда представляет собой одну плотную линию. Сформируйте это, и появится история: N+1, которую пропустила нетерпеливая загрузка, молча добавлено определение связи, ORDER BY на неиндексированном столбце. В работе Laravel это ритуал несколько раз в неделю: телескоп, копия, формат, wince, исправить красноречивый код, повторить. Форматтер сам ничего не диагностирует сам; он делает запрос достаточно разборчивым, чтобы вами канон
Археология по старым запросам
Они есть в каждой долгоживущей системе: сохраненная процедура 2015 года, представление отчета, к которому никто не смеет прикасаться, запрос, встроенный в файл конфигурации с исходным автором и #39;s форматирование (т.е. отсутствие). Прежде чем изменять устаревший SQL, отформатируйте его и прочитайте встык - вы ' будет регулярно находить условия, которые могут ' никогда не быть правдой, присоединяется к таблицам, которые больше не получают записи, и логику текущей команды 's предположения противоречат. Форматирование сначала поворачивает "страшный устаревший запрос иquot; в "длинный, но разборчивый запрос, & quot; что является другой и лучшей проблемой.
Сравнение версий запросов
Когда номера отчета 's меняются между выпусками, возникает вопрос & quot; что изменилось в запросе, & quot; и ответ требует разделения двух версий - что работает только в том случае, если обе сначала отформатированы одинаково. Отформатируйте обе с одинаковыми настройками, а затем запустите их через Инструмент текстового дифференциала: Шум исчезает, и две изменившиеся линии стоят особняком. В конце концов, эта точная последовательность нашла мою ошибку внутреннего стыка. я сейчас делаю это перед полтора дня спутанности, а не после.
Учебное обучение и документация
SQL в учебных пособиях, книгах и внутренних документах читается гораздо больше раз, чем пишется читателями, менее знакомыми со схемой, чем автор. Отформатированные примеры с ключевыми словами в верхнем регистре и структурой "одна концепция за строку" значительно легче изучить - структура преподает наряду с контентом. Когда я пишу документацию со встроенными запросами, каждый сначала проходит через форматировщик; неформатированный SQL в документах сообщает читателю, что автор не ' не ожидайте, что кто-то действительно прочитает его.
Соглашения о форматировании по сравнению
| Выбор условности | Вариант А | Вариант Б | мой взгляд |
|---|---|---|---|
| Случай с ключевым словом | SELECT (верхняя часть) |
select (жнейка) |
Верхний регистр - выживает в контекстах без выделения |
| Идентификационный падеж | змея_чехол | Определения таблиц сопоставления | Определения совпадать; никогда не боритесь со схемой |
| запятые | отставание (id,)) |
ведущий (, id)) |
Отставание, но лидерство оправданно - просто выберите один |
| Макет пункта | Одно предложение на строку | Компактная однострочная | по одному за строку за все, что было в прошлом тривиально |
AND/OR размещение |
Ведущие каждую строку условия | Отслеживание предыдущей строки | Ведущий - логика читается вертикально |
| Условия | ON по своей собственной линии или в пределах JOIN |
Погребенный в средней линии | Видно с присоединением, всегда |
| ширина отступа | 2 пробела | 4 пробела | В любом случае SQL гнездится меньше, чем JSON, поэтому 4 здесь нормально |
Ни одна из этих строк не имеет неправильного ответа, и это's именно ловушка - потому что каждый вариант защищен, команды повторно судили их навсегда, если форматировщик не делает решение механическим. выигрышный ход скучен: выбирайте, настраивайте, форматируйте все и тратьте восстановленное время аргумента на вещи, которые влияют на план выполнения. Остальную часть ежедневного инструментария вокруг этого см Руководство по инструментам кодирования И более широкая Набор инструментов для веб-разработчиков, йо-
часто задаваемые вопросы
Что делает форматтер SQL?
Форматировщик SQL переписывает пробелы запроса's, разрывы строк и оболочку ключевых слов в согласованную, читаемую структуру - каждое предложение в своей строке, условия и столбцы с отступами, ключевые слова нормализованы в один случай. значение оператора's нетронуто: анализаторы SQL полностью игнорируют форматирование, поэтому форматированный запрос возвращает идентичные результаты с идентичным планом выполнения. изменение предназначено исключительно для людей, которые просматривают, отлаживают и поддерживают запрос.
Изменяет ли форматирование SQL производительность запроса?
Нет. пробелы и случай ключевых слов не семантичны в SQL - база данных анализирует обе версии в одном внутреннем представлении и создает один и тот же план выполнения, который вы можете проверить, запустив EXPLAIN на каждом. Форматирование — это предварительное условие для работы, а не само по себе производительность: вы не можете рассуждать об индексах и объединять порядок в запросе, который не можете прочитать.
Должны ли ключевые слова SQL быть прописными или строчными?
Оба действительны - ключевые слова SQL нечувствительны к регистру согласно стандарту - так что это соглашение о читаемости, а не правило правильности. верхние ключевые слова (SELECT, FROM, WHERE) остаются наиболее распространенным выбором, потому что они действуют как встроенное выделение в контекстах, которые лишают цветов: журналы, дифференциалы, терминалы и сообщения в виде текста. Что бы вы ни выбрали, согласованность в кодовой базе имеет гораздо большее значение, чем сам выбор.
Что такое ведущие запятые в SQL и почему люди их используют?
Стиль ведущей запятой ставит запятую в начале каждой строки столбца (, email) вместо конца предыдущего. advocates like it, потому что комментирование любого столбца, кроме первого, никогда не приводит к синтаксической ошибке, а недостающие запятые мгновенно видны на левом поле - реальные преимущества, так как SQL не 't терпит висящую запятую после последнего столбца так, как это делает современный JavaScript. Trailing commas остается более распространенным; либо работает, если применяется последовательно.
Могу ли я отформатировать SQL, сгенерированный ORM, такой как Eloquent или ActiveRecord?
Да, и it's одно из лучших применений форматировщика - вывод отладки ORM поступает как одна плотная линия с машинно-генерируемыми псевдонимами, и форматирование это первый шаг диагностики медленных конечных точек и N+1 проблем.Захват запроса из вашего ORM's loging (Laravel Telescope, ActiveRecord logs), вставить его в Форматтер SQL, и прочитайте, что на самом деле построили ORM, прежде чем достигать EXPLAIN, йо-
Работает ли форматтер с MySQL, PostgreSQL и SQL Server синтаксисом?
Да - практические форматировщики обрабатывают основные диалекты и №39; причуды, сохраняя обратные ссылки MySQL, идентификаторы с двойными кавычками PostgreSQL и :: приведение и квадратные скобки SQL Server, а не перезаписывать их. Стандарт ANSI SQL определяет общее ядро, но ни одна производственная база данных не говорит о чисто стандартном SQL, поэтому допуск диалекта является обязательным требованием для форматирования, который будет полезен для реальных запросов.
Безопасно ли вставлять производственные запросы в онлайн-форматтер SQL?
Только на клиентскую сторону, потому что SQL необычно чувствителен: запросы раскрывают вашу схему, а запросы, скопированные из журналов, часто содержат литералы, такие как электронные письма или идентификаторы в WHERE пункты. выше Toolz.dev SQL форматтер обрабатывает все в вашем браузере без передачи или сохранения - проверьте это самостоятельно, просматривая вкладку "Сеть" во время вставки. Избегайте серверных форматировщиков для чего-либо из производства.
Сохраняет ли форматирование комментариев SQL?
Да - оба -- Линейные комментарии и /* */ Блокировать комментарии проходят через Intact, в отличие от минификации, которая их удаляет. Это делает форматирование безопасным для аннотированных запросов и хранимых процедур, где комментарии несут намерение. Используйте это: однострочный комментарий, объясняющий преднамеренное LEFT JOIN Или необычное состояние — это самая дешевая защита от следующего разработчика «фиксирующего» то, что не сломалось.
