Советы: 1. При SELECT указывайте конкретные столбцы в нужном порядке (не используйте SELECT * FROM). Это безопаснее, понятнее, надёжнее 2. Указывайте колонки с новой строки, а не в одну через запятую 3. Указывайте запятые в начале строки 4. Фильтры ставьте не в JOIN, а в WHERE 5. Вместо комментариев лучше использовать CTE, тк чистый код хорошо читается сам по себе 6. Делайте отступы слева при каждом новом вложенном уровне (SELECT начинает секцию, где перечислены колонки, FROM аналогично и тп)
C CTE аккуратно нужно. Если CTE много и они сложные - запрос становится непрозрачен для парсера\оптимизатора и он может его не распараллелить. С случае postgres так точно. С oracle тоже не рекомендуется, потому-что hint parallel может игнорироваться и вообще план запроса оптимизатор может выбрать странный.
Не знаю почему, но почему-то в нашей компании говорят, что фильтр на Join оптимальнее Where. Может это специфика продукта. С CTE наполовину согласен, мне лично проще прочитать Join на Subquery с отступом, чем листать обратно наверх и смотреть CTE, но только если Subquery очень элеменарный типа select id where full_name in ()
Искуственных не использовал никогда. Видел результат их использования - не понравилось. На счет хранимых процендур говорил здесь ua-cam.com/video/XTHFG5C1a4M/v-deo.html
большие буквы - антипаттерн. разница в читаемости - незначительна. затраты на редактирование не стоят того. тем более, при наличии подсветки. прекращайте так писать.
Материал супер. Подписался сразу. Очень полезная информация
Советы:
1. При SELECT указывайте конкретные столбцы в нужном порядке (не используйте SELECT * FROM). Это безопаснее, понятнее, надёжнее
2. Указывайте колонки с новой строки, а не в одну через запятую
3. Указывайте запятые в начале строки
4. Фильтры ставьте не в JOIN, а в WHERE
5. Вместо комментариев лучше использовать CTE, тк чистый код хорошо читается сам по себе
6. Делайте отступы слева при каждом новом вложенном уровне (SELECT начинает секцию, где перечислены колонки, FROM аналогично и тп)
не раскрыта тема явного использования псевдонимов таблиц
Как всегда - очень приятно слушать. Прикольно, когда сидишь, все это понимаешь, а автора приятно слушать .... и для себя повторяешь :) Удачи ;)
Очень просто и красиво 👍
8:55 - "Секса у нас уже больше нету... его и не было.... " - поржал 😅
😂
Супер мега бомбовые советы для тех, кто работает с базами данных
золото 🏆
спасибо за опыт, которым делитесь
C CTE аккуратно нужно. Если CTE много и они сложные - запрос становится непрозрачен для парсера\оптимизатора и он может его не распараллелить. С случае postgres так точно. С oracle тоже не рекомендуется, потому-что hint parallel может игнорироваться и вообще план запроса оптимизатор может выбрать странный.
Не знаю, как в Postgres, но в MS наоборот может повысить производительность.
Редкий материал. И лайков мало.
А что насчёт запятых, если нужно закомментировать первый столбец в селекте? После него в новой строке запятая же. Обратная ситуация
Да, но просто ставишь какое-то число или строку, а потом комментарий
SELECT
1 - колонка1
, колонка2
, колонка3
Спасибо
Название программы можно?
Которую использовал в видео? Это MySQL Workbench
salem from almaty, qazaq republic. thank you btw support commentary
Есть ли способ логическое выражение передать в WHERE или не передать, по условию? Например если какой-либо из параметров IS NULL
есть
Не знаю почему, но почему-то в нашей компании говорят, что фильтр на Join оптимальнее Where. Может это специфика продукта.
С CTE наполовину согласен, мне лично проще прочитать Join на Subquery с отступом, чем листать обратно наверх и смотреть CTE, но только если Subquery очень элеменарный типа select id where full_name in ()
С точки зрения скорости у MS SQL нет разницы где фильтр, оптимизатор на это не смотрит.
Бьютифаир какой нить юзайте и желательно перейти на хранимые процедуры что бы код sql не торчал в коде бэка
Искуственных не использовал никогда. Видел результат их использования - не понравилось. На счет хранимых процендур говорил здесь ua-cam.com/video/XTHFG5C1a4M/v-deo.html
Первый!!!!
большие буквы - антипаттерн.
разница в читаемости - незначительна.
затраты на редактирование не стоят того.
тем более, при наличии подсветки.
прекращайте так писать.
Кто сказал, что большие буквы антипаттерн?