Чистый код - SQL Edition
HTML-код
- Опубликовано: 14 июл 2021
- В этом видео обсудим, что такое чистый код при написании SQL запросов. Этот код можно оформлять по разному, но я поделюсь своими советами, как я предпочитаю оформлять SQL запросы, чтобы их легче было потом поддерживать.
Обо мне: www.flenov.ru
Мой ИТ блог www.flenov.ru и www.flenov.info
Мой просто блог blo.moe
Tweeter: / flenov
Инстаграмм: / mflenov
Телеграмм: t.me/mflenov
![Eminem - Houdini [Official Music Video]](http://i.ytimg.com/vi/22tVWwmTie8/mqdefault.jpg)
8:55 - "Секса у нас уже больше нету... его и не было.... " - поржал 😅
Советы:
1. При SELECT указывайте конкретные столбцы в нужном порядке (не используйте SELECT * FROM). Это безопаснее, понятнее, надёжнее
2. Указывайте колонки с новой строки, а не в одну через запятую
3. Указывайте запятые в начале строки
4. Фильтры ставьте не в JOIN, а в WHERE
5. Вместо комментариев лучше использовать CTE, тк чистый код хорошо читается сам по себе
6. Делайте отступы слева при каждом новом вложенном уровне (SELECT начинает секцию, где перечислены колонки, FROM аналогично и тп)
не раскрыта тема явного использования псевдонимов таблиц
Очень просто и красиво 👍
Как всегда - очень приятно слушать. Прикольно, когда сидишь, все это понимаешь, а автора приятно слушать .... и для себя повторяешь :) Удачи ;)
Супер мега бомбовые советы для тех, кто работает с базами данных
спасибо за опыт, которым делитесь
Спасибо
Редкий материал. И лайков мало.
А что насчёт запятых, если нужно закомментировать первый столбец в селекте? После него в новой строке запятая же. Обратная ситуация
Да, но просто ставишь какое-то число или строку, а потом комментарий
SELECT
1 - колонка1
, колонка2
, колонка3
C CTE аккуратно нужно. Если CTE много и они сложные - запрос становится непрозрачен для парсера\оптимизатора и он может его не распараллелить. С случае postgres так точно. С oracle тоже не рекомендуется, потому-что hint parallel может игнорироваться и вообще план запроса оптимизатор может выбрать странный.
Не знаю, как в Postgres, но в MS наоборот может повысить производительность.
Есть ли способ логическое выражение передать в WHERE или не передать, по условию? Например если какой-либо из параметров IS NULL
есть
Не знаю почему, но почему-то в нашей компании говорят, что фильтр на Join оптимальнее Where. Может это специфика продукта.
С CTE наполовину согласен, мне лично проще прочитать Join на Subquery с отступом, чем листать обратно наверх и смотреть CTE, но только если Subquery очень элеменарный типа select id where full_name in ()
С точки зрения скорости у MS SQL нет разницы где фильтр, оптимизатор на это не смотрит.
Название программы можно?
Которую использовал в видео? Это MySQL Workbench
Первый!!!!
Бьютифаир какой нить юзайте и желательно перейти на хранимые процедуры что бы код sql не торчал в коде бэка
Искуственных не использовал никогда. Видел результат их использования - не понравилось. На счет хранимых процендур говорил здесь ruclips.net/video/XTHFG5C1a4M/видео.html