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

Введение

Один из самых простых, но наиболее эффективных способов отточить свои навыки программиста — сделать свой код более читабельным. Читаемый код делает его более интерпретируемым, более воспроизводимым и упрощает отладку. Лучший способ сделать ваш код более читабельным — это применить некоторые правила или стандарты, чтобы сделать его согласованным и чистым.

С учетом сказанного я собираюсь поделиться с вами восемью советами по написанию высококлассного SQL-кода:

Не забудьте ПОДПИСАТЬСЯ здесь, чтобы не пропустить новую статью о руководствах по науке о данных, хитростях и советах, жизненных уроках и многом другом!

1. Ключевые слова и функции в верхнем регистре

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

Хотя это может показаться придиркой, подобные советы сделают ваш код в десять раз более разборчивым.

Вместо:

select name, date_trunc(register_date, week) from customers

Попробуйте:

SELECT name, DATE_TRUNC(register_date, WEEK) FROM customers

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

Следующий совет, основанный на нашем предыдущем примере, посвящен отступам и выравниванию кода. Рассмотрим два примера — какой из них более разборчив?

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

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

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

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

Не забудьте ПОДПИСАТЬСЯ здесь, чтобы не пропустить новую статью о руководствах по науке о данных, хитростях и советах, жизненных уроках и многом другом!

3. Примените согласованный тип случая для схем, таблиц, столбцов.

В программировании существует несколько типов типов case, и это лишь некоторые из них:

верблюдЧехол
PascalCase
змея_кейс

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

Вместо:

SELECT 
   firstName
 , LastName
 , child_or_adult 
FROM 
   customers

Попробуйте:

SELECT 
   first_name
 , last_name
 , child_or_adult 
FROM 
   customers

4. Избегайте SELECT *

Это важный совет не только для форматирования, но и для оптимизации запросов (о чем мы поговорим в другой статье!).

Даже если вы обнаружите, что используете почти каждый столбец в таблице, хорошей практикой будет выписать столбцы, которые вам понадобятся. Почему? По мере развития таблицы и добавления/изменения новых столбцов указание имен столбцов упростит выявление потенциальных ошибок в будущем.

Вместо:

SELECT 
   *
FROM 
   customers

Попробуйте:

SELECT 
   name
 , height
 , age
 , salary
FROM 
   customers

Не забудьте ПОДПИСАТЬСЯ здесь, чтобы не пропустить новую статью о руководствах по науке о данных, хитростях и советах, жизненных уроках и многом другом!

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

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

Ознакомьтесь с этой статьей, если вы хотите узнать о CTE более подробно, но по своей сути CTE создают временную таблицу, которая позволяет вам запросить запрос.

Вместо:

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")

Попробуйте:

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

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

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

6. Описательные имена переменных

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

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

Просто прочитав сами имена переменных, становится ясно, что первый CTE извлекает людей из Торонто, а второй CTE получает среднюю зарплату женщин.

С другой стороны, это был бы пример плохого соглашения об именах (которое я действительно видел раньше):

with table_one as (
   SELECT DISTINCT 
      name
   FROM 
      population
   WHERE 
      country = "Canada"
      AND city = "Toronto"
)
, table_two as (
   SELECT 
      AVG(salary) as var_1
   FROM 
      salaries
   WHERE 
      gender = "Female"
)
SELECT 
   name
,  salary
FROM 
   People
WHERE 
   name IN(SELECT name FROM table_one)
   AND salary >= (SELECT var_1 FROM table_two)

7. Упростите код, используя временные функции

Временные функции — отличный способ

Разрушение кода
Написание более чистого кода
И возможность повторно использовать код.

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

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

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

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

8. Значимые комментарии

Вот самое важное правило при написании комментариев: Пишите комментарии только тогда, когда это необходимо.

Следуя предыдущим семи советам (используя описательные имена, модульность кода, написание чистого кода и т. д.), вам не нужно будет писать много комментариев.

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

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

# Getting names of people in Toronto, Canada
with table1 as (
   SELECT DISTINCT name
   FROM population
   WHERE country = "Canada"
         AND city = "Toronto"
)
# Getting the average salary of females
, table2 as (
   SELECT AVG(salary) as var1
   FROM salaries
   WHERE gender = "Female"
)

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

Спасибо за прочтение!

Не забудьте ПОДПИСАТЬСЯ здесь, чтобы не пропустить новую статью о руководствах по науке о данных, хитростях и советах, жизненных уроках и многом другом!

Не знаете, что читать дальше? Я подобрал для вас еще одну статью:

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

и еще один:

10 лучших визуализаций данных 2021 года
Потрясающие визуализации о распределении богатства, окружающей среде, COVID-19 и многом другом!towardsdatascience.com

- Теренс Шин

Если вам понравилось, ПОДПИСАТЬСЯ на мой канал для получения эксклюзивного контента!
Аналогичным образом вы также можете СЛЕДУЙТЕ за мной на Medium
Подпишитесь на мою личную рассылку
Подпишитесь на меня в LinkedIn для получения другого контента

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

Введение

1. Ключевые слова и функции в верхнем регистре

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

3. Примените согласованный тип случая для схем, таблиц, столбцов.

4. Избегайте SELECT *

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

6. Описательные имена переменных

7. Упростите код, используя временные функции

8. Значимые комментарии

Спасибо за прочтение!

- Теренс Шин

Вопросы по теме