CTE, представления, табличные переменные, временные переменные - что выбрать

[@Денис-д1у2д]

Супер! Спасибо большое, Михаил!

[@reflex5989]

cte еще для рекурсий классно

[@viktorgladkih8048]

Круто. Спасибо :))

[@crackcoder651]

Как панель задач такую же сделать?

[@Dev-lessons]

Это Windows 11.

[@leonardt1798]

Сорян, всё круто, но я сейчас посмотрел видос, что процедуры зло и нельзя мешать логику с данными (что конечно же звучит логично) и у меня вопрос )) Что считать логикой, а что простой выборкой, временные таблицы это логика или же нет? Просто так совпало, что я использую процедуры на стороне БД и поступила команда от них избавиться и у меня дилемма, что писать в коде, а что оставить в sql. Спасибо)

[@Dev-lessons]

Я предпочитаю в SQL делать только выборку и там использовать только чистый SQL и минимум хранимых процедур. Идеал - вообще ни одной хранимой процедуры или функции, только SELECT, но к такому сложно прийти. Всегда что-то будет на сервере. А вот что оставлять, тут каждый случай решается в отдельности.

[@leonardt1798]

@@Dev-lessons опять все переписывать )), хорошо, Спасибо )

[@alexandershcherbak4183]

0

[@IgorGallemar]

Засчитано :)

[@ДискотрактористПетрович]

если у вас есть жирная тугая вьюха, и вы собираетесь ее фильтровать, то советую загнуть ее сперва целиком во времянку, а уже потом писать на нее where. скорострельность вас приятно удивит

[@Dev-lessons]

Скорострельность - это скорость выполнения запроса? Я не знаю, как другие базы данных, но MS SQL Server оптимизатор не смотрит на то, что он выполняет View или SQL без представления. Ни разу не видел разницы.

[@ДискотрактористПетрович]

@@Dev-lessons я точно говорю, что из сложной вью гораздо дольше селектит где несколько where или джоинов, чем из времянки от этой вью

[@JohnDoe-tm1rv]

View в базе данных, как и триггеры - это прямой путь в сумашедший дом в будущем, потому что потом совершенно невозможно понять что происходит с базой.

[@Dev-lessons]

Может, если вывести все это из под контроля и слишком много создавать представлений

[@JohnDoe-tm1rv]

@@Dev-lessons Дело в реализации в конкоетгых серверах, оптимизация плана выполнения запроса между джоиными View работает гораздо хуже чем просто на таблицах. Если у тебя медленно работает запрос с использованиес пары тройки View то у тебя просто оуки связаны для его оптимизации. Вью еще так сяк можно для секюрити использовать, чтобы фитьтровать стрлчки данных и давать только выбранные столбцы, потому что на View можно давать права другие чем на таблицы. Для всего остального категорически не рекомендую использовать

[@ivanshipilov4265]

Ну не всегда. Тут зависит от реализации и того для чего это в конечном итоге было нужно. например партиционирование без триггеров реализовать почти не реально, а без View тоже достаточно не просто обойтись если ты работаешь с чем-то вроде бухгалтерских программ, отчетов или аналитики, для последней особенно. Аналитика достаточно сильно грузит базу. Она запускает аггрегирование и /или фулскан всего и блокирует на запись чтение. Поэтому для таких ситуаций часто держат либо отдельную реплику под аналитику либо создают materilizes view. Раз у так вышло что у нас аналитика берется с SQL а не с ClickHouse. А чтобы не путаться приходится хранить в других схемах.... (

[@IgorGallemar]

Первый!!!!