🤬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-ю часть с лучшими практиками.
Но хочу все же подчеркнуть, что какой-то единой истины нет в плане форматирования, поэтому мне интересно как вы в работе форматируете или какой автоформаттер используете?
Пишите в комментариях 👇

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

Могла бы сейчас онлайн шопиться, но у Остина я вызываю сомнения. 😔
Пришлось достать чтиво в виде DAMA-DMBOK.

Кстати, с ужасом осознала, что когда стрессую, то начинаю заедать вкусняшками или мониторить маркетплейсы.
А я-то все думала, что я не такая, я жду трамвая…

А как вы справляетесь со стрессом или просто плохим настроением?

P.s. На главную переходила, не работает

У меня тотальные проблемы с чтением.

Я плохо переношу художественную литературу, моему центру удовольствия довольно трудно угодить. Кажется, последнее, что я читала уже после школы был И.Ефремов «Туманность Андромеды».

Зато мне нравится читать что-то связанное с историей или профессиональную литературу.
Есть правда нюанс: как-то мало времени получается на это выделять. Мне нужен какой-то стимул.

В итоге вспомнила, что вообще-то есть канал и решила, что буду читать и делать конспекты с главными тезисами и делиться ими с вами.

Закоммичусь на чтение 4х книг:

🤓 DAMA-DMBOK - свод правил по управлению данными. Настольная книга серьезных дата-людей.
🤓Lean Analytics – своего рода путеводитель по созданию стартапа. Книга рассказывает о том, как аналитика может помочь в развитии собственного бизнеса. Фактически Lean Analytics продолжает идею так называемого «бережливого стартапа», которая берет начало в книге (The Lean Startup Эрика Риса.
🤓 Mastering Leadership - что-то часто стала мелькать эта книга в постах LinkedIn. По идее книга для CEO и руководителей высшего звена, но думаю, что для общего развития будет полезна всем.
🤓 Storytelling with data - ну куда уж без этого. Название говорит само за себя.

А что вы читаете? Что у вас в списке?

#книги