Сорян, всё круто, но я сейчас посмотрел видос, что процедуры зло и нельзя мешать логику с данными (что конечно же звучит логично) и у меня вопрос )) Что считать логикой, а что простой выборкой, временные таблицы это логика или же нет? Просто так совпало, что я использую процедуры на стороне БД и поступила команда от них избавиться и у меня дилемма, что писать в коде, а что оставить в sql. Спасибо)
Я предпочитаю в SQL делать только выборку и там использовать только чистый SQL и минимум хранимых процедур. Идеал - вообще ни одной хранимой процедуры или функции, только SELECT, но к такому сложно прийти. Всегда что-то будет на сервере. А вот что оставлять, тут каждый случай решается в отдельности.
@@Dev-lessons Дело в реализации в конкоетгых серверах, оптимизация плана выполнения запроса между джоиными View работает гораздо хуже чем просто на таблицах. Если у тебя медленно работает запрос с использованиес пары тройки View то у тебя просто оуки связаны для его оптимизации. Вью еще так сяк можно для секюрити использовать, чтобы фитьтровать стрлчки данных и давать только выбранные столбцы, потому что на View можно давать права другие чем на таблицы. Для всего остального категорически не рекомендую использовать
Ну не всегда. Тут зависит от реализации и того для чего это в конечном итоге было нужно. например партиционирование без триггеров реализовать почти не реально, а без View тоже достаточно не просто обойтись если ты работаешь с чем-то вроде бухгалтерских программ, отчетов или аналитики, для последней особенно. Аналитика достаточно сильно грузит базу. Она запускает аггрегирование и /или фулскан всего и блокирует на запись чтение. Поэтому для таких ситуаций часто держат либо отдельную реплику под аналитику либо создают materilizes view. Раз у так вышло что у нас аналитика берется с SQL а не с ClickHouse. А чтобы не путаться приходится хранить в других схемах.... (
если у вас есть жирная тугая вьюха, и вы собираетесь ее фильтровать, то советую загнуть ее сперва целиком во времянку, а уже потом писать на нее where. скорострельность вас приятно удивит
Скорострельность - это скорость выполнения запроса? Я не знаю, как другие базы данных, но MS SQL Server оптимизатор не смотрит на то, что он выполняет View или SQL без представления. Ни разу не видел разницы.
Супер! Спасибо большое, Михаил!
Круто. Спасибо :))
cte еще для рекурсий классно
Как панель задач такую же сделать?
Это Windows 11.
Сорян, всё круто, но я сейчас посмотрел видос, что процедуры зло и нельзя мешать логику с данными (что конечно же звучит логично) и у меня вопрос ))
Что считать логикой, а что простой выборкой, временные таблицы это логика или же нет?
Просто так совпало, что я использую процедуры на стороне БД и поступила команда от них избавиться и у меня дилемма, что писать в коде, а что оставить в 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 или джоинов, чем из времянки от этой вью