В SQL Server (по крайней мере) я понимаю, что хранимые процедуры оптимизируются во время компиляции и поэтому в целом более эффективны, чем представления.Я не уверен, но я подозреваю, что, выполняя SPRC против представления, вы можете потерять любую оптимизацию, полученную таким образом.
Далее, почему?Как и в предыдущем постере, вы можете выполнять больше соединений, чем нужно, если одно или несколько представлений, которые вы включаете, сами состоят из многочисленных объединений, и это не будет очевидно.
Кроме того, я понимаю, что одной из основных причин использования представлений является представление данных таблицы в формате, который может использовать пользователь, при одновременной защите данных таблицы от случайных изменений.Поскольку результирующий набор из SPROC не подлежит вставкам и обновлениям, этот момент является спорным.
Поскольку хранимая процедура по своему дизайну принимает параметры, не позволяет пользователю напрямую взаимодействовать с данными таблицы и может выполнять любую логику запроса, которую вы можете использовать в представлении (плюс многое другое), кажется, чтоЯ считаю, что (за некоторыми исключениями) главная причина, по которой можно это сделать, состоит в том, чтобы упростить CODING при потенциальной стоимости производительности и ремонтопригодности (что если кто-то изменит одно из представлений, не осознавая, что ваш SPROC зависит от него?)
Я рекомендую закодировать все это в SPROC, если нет веских оснований поступить иначе.,.