Хранимые Процедуры И Представления
Я использовал оба, но то, что я не ясно, когда я должен предпочесть один над другим. Я имею в виду, что я знаю, что хранимая процедура может принимать параметры...но на самом деле мы все еще можем выполнять то же самое, используя представления тоже правильно ?
Итак, учитывая производительность и другие аспекты, когда и почему я должен предпочесть один над другим ?
8 ответов:
Ну, я бы лучше использовал хранимый proc для инкапсуляции кода и управления разрешениями.
представление на самом деле не инкапсуляция: это макрос, который расширяется. Если вы начнете присоединяться к представлениям довольно скоро, у вас будут некоторые ужасные запросы. Да они можете присоединиться, но они не должны..
говоря, что представления-это инструмент, который имеет свое место (например, индексированные представления), такие как хранимые процессы.
преимущество представлений заключается в том, что они могут рассматриваться так же, как таблицы. Вы можете использовать, где получить отфильтрованные данные из них, присоединиться к ним и т. д. Вы даже можете вставить в них данные, если они достаточно просты. Представления также позволяют индексировать их результаты, в отличие от хранимых процедур.
представление подобно одному сохраненному оператору запроса, оно не может содержать сложную логику или несколько операторов (за пределами использования union и т. д.). Для всего сложного или настраиваемого с помощью параметров вы бы выбрали хранимые процедуры, которые обеспечивают гораздо большую гибкость.
обычно в архитектуре базы данных используется комбинация представлений и хранимых процедур, и, возможно, по очень разным причинам. Иногда это для достижения обратной совместимости в sprocs, когда схема реинжиниринг, иногда для того, чтобы сделать данные более управляемыми по сравнению с тем, как они хранятся изначально в таблицах (де-noramlized представления).
интенсивное использование представлений может привести к снижению производительности, так как это более трудным для SQL Server, чтобы оптимизировать эти запросы. Однако можно использовать индексированные представления, которые фактически могут повысить производительность при работе с соединениями так же, как и индексированные таблицы. Существуют гораздо более жесткие ограничения на разрешенный синтаксис при реализации индексированных представлений и много тонкостей в том, чтобы фактически заставить их работать в зависимости от выпуска SQL Server.
представления больше похожи на таблицы, чем на хранимые процедуры.
главным преимуществом хранимых процедур является то, что они позволяют включать логику (сценарии). Эта логика может быть такой же простой, как IF/ELSE или более сложной, например do WHILE loops, SWITCH/CASE.
я соотношу использование хранимых процедур с необходимостью отправки / получения транзакций в базу данных и из нее. То есть, всякий раз, когда мне нужно отправить данные в мою базу данных, я использую хранимую процедуру. То же самое верно, когда я хочу обновить данные или запрашивать базу данных для информации, которая будет использоваться в моем приложении.
представления базы данных отлично подходят для использования, когда вы хотите предоставить подмножество полей из данной таблицы, чтобы пользователи MS Access могли просматривать данные без риска измените его и убедитесь, что ваши отчеты будут генерировать результаты anticpated.
представления полезны, если существует определенная комбинация таблиц или подмножество данных, которые вы последовательно хотите запросить, например, пользователь, присоединенный с его разрешениями. Представления должны фактически рассматриваться как таблицы.
хранимые процедуры-это фрагменты кода sql, которые "компилируются", как это происходит, чтобы работать более оптимально, чем случайный другой запрос. План выполнения кода sql в хранимой процедуре уже построен, поэтому выполнение выполняется немного более гладко, чем у обычного sql заявление.
два фактора.
используйте хранимую процедуру вместо представления, если вы не хотите, чтобы вставка была возможна. Вставка в представление может не дать того, что он, кажется, делает. Он вставит в таблицу строку, которая может не соответствовать запросу из представления, строку, которая затем не появится в представлении; вставляется где-то, но не там, где кажется оператор.
используйте представление, если вы не можете использовать результат хранимой процедуры из другой хранимой процедуры (я никогда не мог сделать последняя работает, по крайней мере с MySQL).