Голосую за комплексный вариант. Для получения данных view, для манипулирования данными хранимка. Хранимые процедуры не предназначены для массовой выборки данных.

Лунтик,

А какие ограничения?
Хватает. Например, есть у вас таблица с миллионом записей. Вам нужна из неё массовая выборка данных с произвольными, приходящими из клиентской части отборами. Если у вас view, вы сделаете из него выборку, наложив нужные условия. У вас правильно сработает оптимизатор, получите нужные Index Seek по наложенным условиям. А что с хранимой процедурой? Переложите миллион записей во временную таблицу и будете потом из них scan'ом отбирать?

Лунтик,
а если в процедура с параметрами, или, скажем, под каждое условие свою процедуру сделать,
По количеству процедур выбирайте, что вам будет лучше. Если у вас нужно получать данные из малого количества таблиц, но с очень разнообразными отборами, то удобнее окажутся view. Еще, наверное, нужно учесть, как работает клиентская часть. У хранимок свои ограничения по использованию, у вьюх - свои.

то получится равнозначно или, все-таки, нет.
Я где-то читал, что хранимки имеют проблемы с оптимизатором запросов.

Вот, выше, товарищ говорит про черепаший темп, имеется в виду, что запрос чисто из-под провайдера выполнится медленнее, чем тот же запрос, но из процедуры??

Товарищ имеет в виду, что 1С работает довольно медленно. Это интерпретируемый язык бизнес-логики и быстрая обработка данных по записям не его предназначение. Поэтому если в 1С программистом неправильно построена работа с базой, можно получить много длительных блокировок. Если программист хочет повесить tablock, засосать таблицу в 1С, обработать и выкинуть результат в базу, то... лучше ему так не делать. :)

вот как раз много фильтров, много соединений, процедур будет дофига, но аргументов против найти не могу.
Можно провести нагрузочное тестирование. Многократный вызов какой-то хранимки и аналогичный многократный вызов представления. Если есть какая-то разница в работе оптимизатора и использовании статистики, она выявится. Будет аргумент.
А можно прикинуться ветошью, и дать админу SQL ТЗ. На создание и тестирование 100500 хранимок. Типа я глупый только представлениями могу :)

Но начинать нужно не с этого. Вытрясти с админа подробности. Почему и зачем. Зачем хранимки. Почему не воспользоваться настройкой прав на таблицы, если админа беспокоит безопасность. Почему не воспользоваться реплицированной readonly базой, если админа беспокоят блокировки. Со своей стороны оценить, какие будут трудозатраты на создание и тестирование 100500 хранимок. Какие трудозатраты на изменение клиентской части и поддержание её в дальнейшем (бизнес-логика вызова большого количества разных хранимок явно сложнее, чем двух-трёх представлений).
Вы же с админом должны вместе работать, а не каждый в свои стороны тянуть.

Ну а если админ просто где-то начитался, что "хранимки-хорошо, а представления-плохо", просто сделай две-три хранимки, которым тупо будешь передавать текст запроса.