{"id":14276,"url":"\/distributions\/14276\/click?bit=1&hash=721b78297d313f451e61a17537482715c74771bae8c8ce438ed30c5ac3bb4196","title":"\u0418\u043d\u0432\u0435\u0441\u0442\u0438\u0440\u043e\u0432\u0430\u0442\u044c \u0432 \u043b\u044e\u0431\u043e\u0439 \u0442\u043e\u0432\u0430\u0440 \u0438\u043b\u0438 \u0443\u0441\u043b\u0443\u0433\u0443 \u0431\u0435\u0437 \u0431\u0438\u0440\u0436\u0438","buttonText":"","imageUuid":""}
Dataism

SELECT style FROM SQL

Бесконечно долго можно смотреть на 3 вещи: огонь, воду и как аналитики спорят, куда ставить запятую в запросе.

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

Но важно понимать, что форматирование - это необходимая вещь.

Поэтому вот небольшой список best practices по код-стайлу.

📌1. SELECT * FROM - антипаттерн.

- таблицы меняются и запрос, содержащий подобную конструкцию, может сломаться.

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

- вопрос производительности. Хорошая статья на эту тему.

📌2. Используйте СTE (с понятным псевдонимом).

- повышение читаемости кода

- дешевле выполнить cte один раз, кэшировать данные, а затем просто повторно использовать набор результатов по мере необходимости в своем коде.

📌3. Используйте комментарии.

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

Например, у вас встретился запрос, вот такого вида:

SELECT manager FROM dict_table 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. Делайте группировку по имени поля, а не по номеру.

Хотя вот статья в защиту номера

Плохо:

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 user_id from empl

Хорошо:

SELECT user_id FROM empl

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

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

Мне лично нравится ставить запятую в конце.

Плохо:

select id, email from users

Хорошо:

SELECT id, email FROM users

📌10. Выравнивание по левому краю.

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

Заключение:

В vs code есть различные форматтеры, так что установите себе что-то подобное и жизнь станет проще.

либо в DataGrip/DBeaver настройте нужное.

Полный гайд с лучшими практиками можно скачать тут.

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

А на какой вы стороне: commas-first или last?

#sql #dataanalytics

Пишите в комментариях 👇

529 показов
45 открытий
0
Комментарии
Написать комментарий...
-3 комментариев
Раскрывать всегда