Когда целесообразно использовать хранимые процедуры против табличных функций - PullRequest
0 голосов
/ 24 июня 2009

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

Чтобы сделать это с сохраненными процессами, мне нужно сохранить набор результатов из хранимого процесса в временных таблицах, как показано ниже:

CREATE TABLE #Top_1000_Customers (
  CustomerCode BIGINT, 
  Firstname VARCHAR(100),
  Surname VARCHAR(100),
  State VARCHAR(),
  MonthlySpend FLOAT)

INSERT INTO #Top_1000_Customers
EXEC FindTop1000Customers()  

SELECT CustomerCode, Firstname, Surname, State, MonthlySpend float
FROM #Top_1000_Customers
WHERE State = 'VIC'  

DROP TABLE #Top_1000_Customers  

Если я сделаю это, используя табличную функцию, этот код будет выглядеть так:

SELECT FindTop1000Customers()
WHERE State='VIC'

Если я захочу, я могу даже объединить табличную функцию с другой таблицей.

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

Существуют ли какие-либо существенные причины, по которым мне было бы лучше использовать хранимые процедуры для выполнения задач такого типа вместо использования табличных функций?

Ответы [ 3 ]

2 голосов
/ 24 июня 2009

Может ли ваша процедура FindTop1000Customers быть выражена в одном операторе SELECT? Если это так, встроенная табличная функция может быть хорошей заменой. Критерии State = 'VIC' будут перенесены в базовые таблицы, и запрос может выполняться намного быстрее.

Если нет, функция с многозначным табличным значением все равно должна будет материализовать полный набор результатов перед применением предложения WHERE. Чтобы перенести фильтр вниз к базовым таблицам, вам необходимо параметризовать функцию, как если бы вы хранили хранимый процесс. И вы сильно потеряете мощность программирования (временные таблицы, динамический SQL и т. Д.).

Я предлагаю статьи Эрланда Соммарскога по Как обмениваться данными между хранимыми процедурами , Условия динамического поиска и Динамический SQL для получения дополнительных идей по этому вопросу.

1 голос
/ 24 июня 2009

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

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

В вашем случае, если вы можете сделать это с обычным просмотром или встроенным TVF, я бы сделал это в первую очередь.

1 голос
/ 24 июня 2009

Существуют ограничения на функции в целом, которые не применяются к хранимым процедурам. См. Руководство по проектированию пользовательских функций .

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...