Представления SQL и Sprocs

Question

Я установил в компании политику, согласно которой весь доступ к данным должен осуществляться через Sprocs. Это включает в себя, выбирает, обновляет, удаляет и вставляет. Мы начинаем наводнять их. Я перебиваю это? Выборы выполняются, а результаты сбрасываются в пользовательский DAL.

У меня такое ощущение, что это вопрос священной войны. Я склоняюсь в сторону, что sprocs излишни для простого выбора, но необходимость для обновлений, вставок и удалений. Одним из аргументов в пользу sprocs является безопасность. Некоторые пользователи не должны иметь доступ к определенным частям приложения. Кто здесь на самом деле создает более одного пользователя на БД для веб-сайта? Нет рук?

Мне также нужно получить статистику по нескольким таблицам. Это один запрос с количеством обращений к UDF. Эти характеристики меняются с каждой минутой. Должен ли я использовать вид или sproc? Я учусь на sproc, так как представление должно было бы в любом случае перестраиваться каждый раз. Это правильное предположение?

Answer 1

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

"Какое дело вы определяете? политика развития, если вы этого не сделаете понять, как работает база данных? "

Вы говорите, что "представление должно было бы просто перестраиваться каждый раз в любом случае". Вы хотите сказать, что любой код с представлением перекомпилируется при каждом запросе? Потому что это абсолютно не так (по крайней мере, в Oracle и SQL Server). Использование представлений является гораздо более гибким способом получения эффективных запросов, чем хранимых процедур, поскольку оптимизатор может повторно оптимизировать ваше представление в зависимости от того, как вы его используете. И как только это будет сделано, план запроса будет кеширован, поэтому он не должен выполнять перекомпиляцию. Показательный пример: Вы создаете это представление:

CREATE VIEW myOrders AS
SELECT c.CustomerID, c.LastName, c.FirstName, o.OrderID, o.OrderPrice
FROM Customers c
LEFT JOIN Orders o
   ON o.CustomerID = o.CustomerID;

Затем вы решаете, что хотите получить список всех клиентов по имени Джон Смит:

SELECT c.CustomerID
FROM myOrders
WHERE c.LastName = 'Smith' AND c.FirstName = 'John';

Поскольку это представление, соединение с «Заказами» оптимизируется. Если бы вы попытались модулировать это в хранимой процедуре, ну, вы не могли. Вам, вероятно, придется сделать еще одно sproc только для этой цели. И довольно скоро вы столкнетесь с проблемой, которая у вас есть, а это тонна едва обслуживаемых процедур.

Почему вы используете хранимые процедуры? Какую проблему вы пытаетесь решить? Инкапсуляция? Я бы сказал, что для SELECT UDF могут быть более полезными. Я также утверждаю, что запросы LINQ-типа на среднем уровне еще более гибкие. Вы пытаетесь оптимизировать производительность с помощью хранимых процедур? Если это так, знайте и понимайте, что каждый выполняемый вами специальный запрос оптимизируется и кэшируется. Если вы используете SQL Server 2005+, вы можете даже заставить его параметризировать и кэшировать планы запросов, даже если вы не указываете параметры явно.

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

Answer 2

В дополнение к хранимым процедурам вы можете разрешить доступ к представлениям. Вы по-прежнему можете контролировать доступ к представлениям, но одно представление может заменить множество хранимых процедур.

Вы также можете группировать хранимые процедуры по функциональности и использовать префикс для каждой группы. Например, cart_AddItem или user_GetPreferences. Это много работы, чтобы реализовать задним числом, но никогда не поздно начать.

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