Dataism: “🤬SELECT style FROM SQL. Часть 1 Бесконечно долго можно смотреть на 3…”

🤬SELECT style FROM SQL. Часть 1

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

Поэтому вот небольшой список best practices по код-стайлу.
📌1. SELECT * FROM - антипаттерн.
- таблицы меняются и запрос, содержащий подобную конструкцию, может сломаться.
- плохо читаемый код запроса, непонятно какие поля выбираются для дальнейшей работы.
- вопрос производительности. Хорошая статья на эту тему: https://tanelpoder.com/posts/reasons-why-select-star-is-bad-for-sql-performance/

📌2. Используйте СTE (с понятным псевдонимом).
- дешевле выполнить подзапрос один раз, сохранить его в памяти, а затем просто повторно использовать набор результатов по мере необходимости в своем коде.
- повышение читаемости кода

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


SELECT manager 
FROM dict 
WHERE city = ‘Зажопинск’

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

📌4. Избегайте подсказок оптимизатору.
Например, вы увидели, что ваши данные со скошенным статистическим распределением и на радостях впихнули в запрос хинт*, чтобы явно указать оптимизатору что делать. Но по мере роста объема данных это распределение может измениться и тогда ваша подсказка будет уже помехой.
*хинт (hint) – это указание оптимизатору запросов, которое переопределяет его поведение по умолчанию на время выполнения SQL запроса.

📌5. Именование колонок должно быть в snake_case стиле.
Хорошо


SELECT
    id,
    email,
    timestamp_trunc(created_at, month) AS signup_month
FROM users

Далее идут более спорные пункты. Да начнутся голодные игры.

📌6. Одиночное join условие должно быть на той же строке что и сам join.
Хорошо


SELECT
    users.email,
    sum(charges.amount) AS total_revenue
FROM users
INNER JOIN charges ON users.id = charges.user_id
GROUP BY email

📌7. Делайте группировку по имени поля, а не по номеру. Хотя вот статья в защиту номера: https://www.getdbt.com/blog/write-better-sql-a-defense-of-group-by-1
Плохо


SELECT department, position, count(id) AS count_empl
FROM empl
GROUP BY 1, 2

Хорошо


SELECT department, position, count(id) AS count_empl
FROM empl
GROUP BY department, position

📌8. Записывайте прописными буквами зарезервированные слова.
Плохо


select a  from empl

Хорошо


SELECT a
FROM empl

Лично мне проще читать код, когда вижу upper case, но в автоматизированных форматтерах это можно регулировать.

📌9. Запятые в начале vs запятые в конце (commas-first/last) + каждое поле в новой строке
Мне лично нравится ставить запятую в конце.
Плохо


select id, email
from users

Хорошо


SELECT
      id,
      email
FROM users

📌10. Выравнивание по левому краю.
Даже не знаю, что вызывает больше споров: выравнивание или запятые. Я выравниваюсь по левому краю.

В vs code есть различные форматтеры, так что установите себе что-то подобное и жизнь станет проще.
https://www.vsixhub.com/vsix/5708/ - как пример
либо в DataGrip настройте нужное)

Объем информации довольно большой, поэтому в следующий раз опубликую 2-ю часть с лучшими практиками.
Но хочу все же подчеркнуть, что какой-то единой истины нет в плане форматирования, поэтому мне интересно как вы в работе форматируете или какой автоформаттер используете?
Пишите в комментариях 👇

#трудовыебудни