Пять лучших практик для написания чистого и профессионального кода SQL

5 рекомендаций по написанию чистого кода SQL
Повысьте уровень своего кода SQL с помощью этих пяти советов!


Введение

SQL - универсальный язык запросов в мире данных. Если вы аналитик данных, специалист по данным, инженер данных, архитектор данных и т. д., Вам нужно уметь писать хороший  и понятный код SQL.

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

Если вы свободно владеете Python или другим языком программирования, некоторые из этих правил могут показаться вам знакомыми, и это потому, что они очень легко переносимы!

Итак, я собираюсь поделиться с вами пятью советами, как писать более чистые и эффективные запросы SQL. Давайте начнем.

1. Стиль программирования

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

<p">Позвольте мне привести вам быстрый пример - какой из следующих двух блоков кода более разборчивый?

SELECT name,height,weight,age,gender,CASE WHEN age<18 THEN "child" ELSE "adult" END AS childOrAdult,salary
FROM People LEFT JOIN Income USING (name)
WHERE height<=200 and age<=65

или

SELECT name
       , height
       , weight
       , age
       , gender
       , CASE WHEN age < 18 THEN "child"
              ELSE "adult"
         END AS childOrAdult
       , salary
FROM People
LEFT JOIN Income USING (name)
WHERE height <= 200
      AND age <= 65

Совершенно очевидно, что второй вариант намного легче читать, и это полностью связано с его стилем программирования! Есть несколько компонентов стиля программирования, но мы собираемся сосредоточиться на отступах и пробелах.

Отступ / выравнивание

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

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

Пробелы

Пробелы относятся к пустому пространству, которое вы используете в своем коде. Например, вместо…

WHERE height<=200 AND age<=65

рассмотрите возможность использования пробелов, чтобы сделать его более разборчивым:

WHERE height <= 200 AND age <= 65

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

2. Модуляризация кода с помощью общих табличных выражений

Использование общих табличных выражений (CTE) - отличный способ разбить код на модули и разбить его так же, как если бы вы разбили эссе на несколько абзацев.

Рассмотрим следующий запрос с подзапросом в предложении WHERE.

SELECT name
       , salary
FROM People
WHERE name in (SELECT DISTINCT name 
                   FROM population 
                   WHERE country = "Canada"
                         AND city = "Toronto")
      AND salary >= (SELECT AVG(salary)
                     FROM salaries
                     WHERE gender = "Female")

Это может показаться несложным для понимания, но что, если бы в подзапросах было много подзапросов или подзапросов? Вот где в игру вступают CTE.

with toronto_ppl as (
   SELECT DISTINCT name
   FROM population
   WHERE country = "Canada"
         AND city = "Toronto"
)
, avg_female_salary as (
   SELECT AVG(salary) as avgSalary
   FROM salaries
   WHERE gender = "Female"
)
SELECT name
       , salary
FROM People
WHERE name in (SELECT DISTINCT FROM toronto_ppl)
      AND salary >= (SELECT avgSalary FROM avg_female_salary)

Теперь ясно, что предложение WHERE фильтрует имена в Торонто. Если вы заметили, CTE полезны, потому что вы можете разбить свой код на более мелкие части, но они также полезны, потому что позволяют назначать имя переменной каждому CTE (например, toronto_ppl и avg_female_salary)

Примечание: стиль программирования применим и к CTE!

Говоря о соглашениях об именах, это приводит к следующему пункту:

3. Соглашения об именах переменных

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

Письмо-оболочка (Letter-casing)

Лично мне нравится использовать snake_case для именования CTE и camelCase для имен столбцов. Вы можете стилизовать свои переменные, как вам нравится, но убедитесь, что вы последовательны.

Вот пример:

with short_people as (
   SELECT firstName
   FROM people
   WHERE height < 165
)
SELECT * FROM short_people

Обратите внимание, как я использовал snake_case для CTE (short_people) и использовал camelCase для firstName.

Описательные имена

В идеале вы хотите, чтобы имена переменных описывали то, что они представляют. Рассмотрим мой предыдущий пример:

with toronto_ppl as (
   SELECT DISTINCT name
   FROM population
   WHERE country = "Canada"
         AND city = "Toronto"
)
, avg_female_salary as (
   SELECT AVG(salary) as avgSalary
   FROM salaries
   WHERE gender = "Female"
)
SELECT name
       , salary
FROM People
WHERE name in (SELECT DISTINCT FROM toronto_ppl)
      AND salary >= (SELECT avgSalary FROM avg_female_salary)

Совершенно очевидно, что первый CTE опрашивает людей из Торонто, а второй CTE получает среднюю зарплату женщин. Это был бы пример плохих соглашений об именах:

with table1 as (
   SELECT DISTINCT name
   FROM population
   WHERE country = "Canada"
         AND city = "Toronto"
)
, table2 as (
   SELECT AVG(salary) as var1
   FROM salaries
   WHERE gender = "Female"
)
SELECT name
       , salary
FROM People
WHERE name in (SELECT DISTINCT FROM table1)
      AND salary >= (SELECT var1 FROM table2)

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

4. Упростите код с помощью временных функций

Временные функции (TEMPORARY FUNCTION) также являются хорошим способом разбить код, написать более чистый код и иметь возможность повторно использовать код.

Рассмотрим следующий пример:

SELECT name
       , CASE WHEN tenure < 1 THEN "analyst"
              WHEN tenure BETWEEN 1 and 3 THEN "associate"
              WHEN tenure BETWEEN 3 and 5 THEN "senior"
              WHEN tenure > 5 THEN "vp"
              ELSE "n/a"
         END AS seniority 
FROM employees 

Вместо этого вы можете использовать временную функцию для захвата предложения CASE.

CREATE TEMPORARY FUNCTION seniority(tenure INT64) AS (
   CASE WHEN tenure < 1 THEN "analyst"
        WHEN tenure BETWEEN 1 and 3 THEN "associate"
        WHEN tenure BETWEEN 3 and 5 THEN "senior"
        WHEN tenure > 5 THEN "vp"
        ELSE "n/a"
   END
);
SELECT name
       , seniority(tenure) as seniority
FROM employees
 

Благодаря временной функции сам запрос становится намного проще и читабельнее, и вы можете повторно использовать эту функцию!

5. Пишите полезные комментарии

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

При этом комментарии полезны, когда сам код не может объяснить, чего вы пытаетесь достичь. Комментарии обычно отвечают «почему» вы что-то делаете, а не «что» вы делаете.

Вот пример плохого комментария:

# Получение имен людей в Торонто, Канада
with table1 as (
   SELECT DISTINCT name
   FROM population
   WHERE country = "Canada"
         AND city = "Toronto"
)
# Получение средней зарплаты женщин
, table2 as (
   SELECT AVG(salary) as var1
   FROM salaries
   WHERE gender = "Female"
)

Это плохие комментарии, потому что они говорят нам то, что мы уже знали, читая сам код. Помните, что комментарии обычно отвечают «почему» вы что-то делаете, а не «что» вы делаете.

Итоги

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

Но это еще не конец темы! Вот еще больше рекомендаций по написанию эффективного кода SQL и T-SQL.

 

Вас заинтересует / Intresting for you:

Типы данных SQL: стандарт ANSI...
Типы данных SQL: стандарт ANSI... 4858 просмотров Дэн Sat, 05 Jun 2021, 09:43:17
SQL: Правила выполнения однота...
SQL: Правила выполнения однота... 1442 просмотров Дэйзи ак-Макарова Sat, 31 Jul 2021, 06:47:05
Назначение языка SQL и необход...
Назначение языка SQL и необход... 3573 просмотров Ирина Светлова Mon, 28 Jun 2021, 19:23:28
Правила именование объектов SQ...
Правила именование объектов SQ... 9750 просмотров Дэн Sat, 05 Jun 2021, 09:02:07
Войдите чтобы комментировать

ildergun аватар
ildergun ответил в теме #10793 1 год 4 мес. назад
Отличные правила написания кода SQL! Маст Хэв!)
iVoron аватар
iVoron ответил в теме #10359 2 года 2 мес. назад
Отличная серия статей по написанию читабельного чистого кода на SQL и стилю программирования. Спасибо данному порталу!