Skip to content

Как правильно форматировать код SQL

Пересказ статьи Dorota Wdzięczna. How to Properly Format SQL Code


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

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


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

SELECT id, FirstName, LASTNAME,c.nAme FROM people p left JOIN cities AS c on c.id=p.cityid;


Этот запрос SQL был написан без применения каких-либо правил форматирования. Теперь сравните его с отформатированным запросом ниже, который представляет тот же самый код:

SELECT p.PersonId,
p.FirstName,
p.LastName,
c.Name
FROM Person AS p
LEFT JOIN City AS c
ON p.CityId = c.CityId;

Видите разницу? Что является более читабельным? Какой запрос проще понять?

Очевидно, что первый запрос не очень легко читается. Помимо этого, имеется проблема быстрого внесения изменений в этот код. Если бы вам захотелось сравнить этот запрос с другим подобным запросом, это стало бы непростой задачей. Второй запрос совершенно отличается в этом отношении, несмотря на то, что он содержит точно такой же код, он легко читается, в него легко вносить правки, и его было бы легко сравнивать с другим хорошо отформатированным кодом. Правильное форматирование кода SQL помогает программистам избегать ошибок.

ОК, теперь вы понимаете, почему форматирование кода SQL является хорошей идеей. Теперь самое время узнать, как это делается.

Как форматировать код SQL


Существуют различные подходы к форматированию кода. Некоторые программисты SQL имеют свой индивидуальный стиль и предпочтения при форматировании запросов SQL. У них есть опыт в программировании и они следуют правилам, удобным для них. Не так плохо, если вы единственный работаете над собственными проектами, но что, если вы работаете совместно с коллегами?

Работа в команде станет проблематичной, если каждый программист будет писать код, используя свой собственный индивидуальный стиль. Код будет представлять смесь правил в одном проекте. Решением будет выработать набор принципов, единых для всей команды. Но что, если код должен читаться или корректироваться людьми за пределами компании? Лучшим решением в общем случае является следование стандарту форматирования SQL. Не существует какого-то одного документа в этом роде, но имеются некоторые общие соглашения о стандарте и рекомендации, написанные экспертами в SQL. Кроме того, имеется много инструментов, которые помогают форматировать код SQL на основе этого стандарта. В данном руководстве мы обсудим общие и популярные правила, основанные на данном стандарте.

Именование объектов


Сначала обсудим общие правила относительно именования объектов базы данных. Вот наиболее общие правила:

  • Избегайте имен таблиц/столбцов во множественном числе. Лучше использовать employee вместо employees.

  • Если имя таблицы или столбца должно состоять более чем из одного слова, используйте нижнее подчеркивание между ними, например employee_city. Некоторые профессионалы предпочитают использовать то, что называется стилем CamelCase, например, EmployeeCity. Предпочтительный стиль различается для различных реляционных систем баз данных.

  • Проверяйте, что имя пока не используется как ключевое слово в SQL.

  • Если имя совпадает с ключевым словом SQL, заключайте его в кавычки.

  • Имя объекта в базе данных для таблицы или столбца должно быть уникальным и не слишком длинным. Избегайте специальных символов типа $, &, * и т.п. (используйте только буквы, числа и нижнее подчеркивание)

  • Используйте нижнее подчеркивание в имени только при необходимости.

  • Не начинайте имя с нижнего подчеркивания.

  • Используйте комментарии только при необходимости.

  • Избегайте сокращений, но, если вы используете их, убедитесь, что они будут понятны.

  • Избегайте давать одно и то же имя таблице и столбцу.

  • Используйте те же самые правила именования для алиасов столбцов или таблиц.

  • Включайте ключевое слово AS при создании алиасов, поскольку это делает код более читабельным.

  • Для столбца первичного ключа избегайте имени id. Хорошим приемом является комбинация Id с именем таблицы, например, id_employee.


Выравнивание


Большинство экспертов рекомендует новую строку начинать с ключевого слова слева, а остальной код - справа, например:

SELECT p.PersonId,
p.FirstName,
p.LastName,
c.Name
FROM Person AS p
JOIN City AS c
ON p.CityId = c.CityId;

Отступы


Свободное использование новых строк может на самом деле улучшить читабельность SQL-запроса. Неплохо начинать с новой строки каждое отдельное предложение и каждый отдельный столбец после запятой. Также хорошо окружать пробелами оператор равенства, использовать пробелы перед и после апострофов, а также после запятой.
В последующих разделах более подробно рассматриваются отступы в запросах SQL различных типов.

Комментарии


Избегайте написания большого числа комментариев в коде. Конечно, есть случаи, когда комментарии необходимы. В этом случае обычно лучше использовать многострочные комментарии, которые открываются символами /* и закрываются символами */. Рекомендуется писать комментарий такого типа с новой строки, а не продолжать на строке исполняемого кода. Комментарий следует писать выше строки кода SQL, к которой он относится, используя тот же отступ. Например:

SELECT p.PersonId,
p.FirstName,
p.LastName,
/* Столбец Name - это имя города: */
p.Name,
FROM Person AS p
WHERE p.Name = 'New York';

В код SQL можно также добавлять однострочные комментарии. Комментарии этого типа вводятся двойным дефисом (--) в начале текста комментария. Весь текст (до конца строки) после этих символов считается комментарием.

SELECT -- мы должны удалить этот столбец p.PersonId,
p.FirstName,
p.LastName,
p.Name
FROM Person AS p;

Запросы SELECT


В запросах этого типа SELECT является первым словом в команде. Если после SELECT имеется много столбцов, лучше разделить их, поместив каждый столбец на отдельной строке. Каждая новая строка должна иметь отступ. Обязательно ставьте запятые в конце каждой строки, а не в начале.

SELECT p.PersonId,
p.FirstName,
p.LastName,
c.Name
FROM Person AS p;

Что касается ключевых слов FROM, WHERE, ORDER BY, GROUP BY и HAVING, пишите каждое с новой строки без отступов.

SELECT p.PersonId,
p.FirstName,
p.LastName,
p.Name,
FROM Person AS p
WHERE p.Name = 'New York';

Если предложение WHERE содержит более одного условия, разделите каждое условие новой строкой с отступом, начиная эту строку условными операторам AND или OR в пределах предложения WHERE.

SELECT p.PersonId,
p.FirstName,
p.LastName,
p.Name
FROM Person AS p
WHERE p.Name = 'New York'
OR p.Name = 'Chicago';

Операторы JOIN


Если вы соединяете таблицы, используйте новую строку для операторов INNER JOIN, LEFT JOIN и т.д. Оператор ON записываете с новой строки с отступом в пределах оператора JOIN. Однако если имеется более одного условия, используйте новую строку с отступом перед условным оператором AND или OR.

SELECT p.PersonId,
p.FirstName,
p.LastName,
c.Name
FROM Person AS p
JOIN City AS c
ON p.CityId = c.CityId;

Длинный и вложенный запрос SQL


Длинные запросы иногда содержат подзапросы. В этой ситуации подзапрос следует писать на новой строке с отступом.

Для структуры CASE размещайте каждый WHEN и END на новой строке.

SELECT p.PersonId,
p.FirstName,
p.LastName,
CASE
WHEN p.Age < 18 THEN 'below 18'
WHEN p.Age >= 18 THEN '18 or more'
END AS Age
FROM Person AS p;

Запросы SQL других типов


Подобные правила применяются к запросам, которые модифицируют, вставляют или удаляют данные.

Используйте отступ для VALUES в запросах на вставку:

INSERT INTO Car(id_car, name, year) VALUES
(1, 'Audi', 2010) ;

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

INSERT INTO Car(id_car, name, year) VALUES
(1, 'Audi', 2010) ,
(2, 'Skoda', 2015) ;

Аналогичным образом, в запросе UPDATE записывайте предложения SET и WHERE, как и в операторе SELECT с новой строки без отступа:

UPDATE Car
SET year = 2012
WHERE Name = 'Audi';

или в запросе DELETE:

DELETE FROM Car
WHERE Name = 'Audi';





Как плохое форматирование кода SQL вызывает проблемы


Ниже можно увидеть один пример, когда плохое форматирование вызывает проблемы в запросе, в котором запятые стоят в начале каждой строки:

SELECT /* мы должны удалить этот столбец */ p.PersonId
, p.FirstName
, p.LastName
, p.Name
FROM Person AS p
WHERE p.Name = 'New York';

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

Другая ошибка может возникнуть, если вы не используете отступы и новые строки. Например:

Select person.id_person, person.name, person.age, person.description, person.city from person  where person.age>20 and person.city = ( select name from city where id_city>20)

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

Множество проблем можно обнаружить, если запрос плохо отформатирован, особенно громоздкий запрос с сотнями строк кода.

Заключение


Игнорирование стандарта форматирования SQL может вызвать значительные проблемы, когда вы работаете совместно с другими программистами. Надлежащее форматирование сделает ваш код SQL легче читаемым и поможет предотвратить ошибки при внесении изменений в ваш код.

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

Категории: T-SQL

Обратные ссылки

Нет обратных ссылок

Комментарии

Показывать комментарии Как список | Древовидной структурой

Нет комментариев.

Автор не разрешил комментировать эту запись

Добавить комментарий

Enclosing asterisks marks text as bold (*word*), underscore are made via _word_.
Standard emoticons like :-) and ;-) are converted to images.

To prevent automated Bots from commentspamming, please enter the string you see in the image below in the appropriate input box. Your comment will only be submitted if the strings match. Please ensure that your browser supports and accepts cookies, or your comment cannot be verified correctly.
CAPTCHA

Form options

Добавленные комментарии должны будут пройти модерацию прежде, чем будут показаны.