CTE, представления, табличные переменные, временные переменные - что выбрать
HTML-код
- Опубликовано: 21 сен 2024
- Есть сразу несколько вариантов изолировать запрос, но далеко не всегда это изоляция данных результата запроса. В этом видео я решил обсудить, что и когда использовать. Я рассматриваю преимущества и недостатки каждой из этих технологий.
Обо мне: www.flenov.ru
Мой ИТ блог www.flenov.ru и www.flenov.info
Мой просто блог blo.moe
Tweeter: / flenov
Инстаграмм: / mflenov
Телеграмм: t.me/mflenov
Супер! Спасибо большое, Михаил!
Круто. Спасибо :))
Сорян, всё круто, но я сейчас посмотрел видос, что процедуры зло и нельзя мешать логику с данными (что конечно же звучит логично) и у меня вопрос ))
Что считать логикой, а что простой выборкой, временные таблицы это логика или же нет?
Просто так совпало, что я использую процедуры на стороне БД и поступила команда от них избавиться и у меня дилемма, что писать в коде, а что оставить в sql.
Спасибо)
Я предпочитаю в SQL делать только выборку и там использовать только чистый SQL и минимум хранимых процедур. Идеал - вообще ни одной хранимой процедуры или функции, только SELECT, но к такому сложно прийти. Всегда что-то будет на сервере. А вот что оставлять, тут каждый случай решается в отдельности.
@@Dev-lessons опять все переписывать )), хорошо, Спасибо )
0
Засчитано :)
View в базе данных, как и триггеры - это прямой путь в сумашедший дом в будущем, потому что потом совершенно невозможно понять что происходит с базой.
Может, если вывести все это из под контроля и слишком много создавать представлений
@@Dev-lessons Дело в реализации в конкоетгых серверах, оптимизация плана выполнения запроса между джоиными View работает гораздо хуже чем просто на таблицах. Если у тебя медленно работает запрос с использованиес пары тройки View то у тебя просто оуки связаны для его оптимизации. Вью еще так сяк можно для секюрити использовать, чтобы фитьтровать стрлчки данных и давать только выбранные столбцы, потому что на View можно давать права другие чем на таблицы. Для всего остального категорически не рекомендую использовать
Ну не всегда. Тут зависит от реализации и того для чего это в конечном итоге было нужно. например партиционирование без триггеров реализовать почти не реально, а без View тоже достаточно не просто обойтись если ты работаешь с чем-то вроде бухгалтерских программ, отчетов или аналитики, для последней особенно. Аналитика достаточно сильно грузит базу. Она запускает аггрегирование и /или фулскан всего и блокирует на запись чтение. Поэтому для таких ситуаций часто держат либо отдельную реплику под аналитику либо создают materilizes view. Раз у так вышло что у нас аналитика берется с SQL а не с ClickHouse. А чтобы не путаться приходится хранить в других схемах.... (
если у вас есть жирная тугая вьюха, и вы собираетесь ее фильтровать, то советую загнуть ее сперва целиком во времянку, а уже потом писать на нее where. скорострельность вас приятно удивит
Скорострельность - это скорость выполнения запроса? Я не знаю, как другие базы данных, но MS SQL Server оптимизатор не смотрит на то, что он выполняет View или SQL без представления. Ни разу не видел разницы.
@@Dev-lessons я точно говорю, что из сложной вью гораздо дольше селектит где несколько where или джоинов, чем из времянки от этой вью
Первый!!!!
Как панель задач такую же сделать?
Это Windows 11.