我们目前正在为大多数报告使用存储过程,但我希望能够灵活地使用更多标准加入结果集。
要使用存储过程执行此操作,我需要将来自storedproc的结果集存储在临时表中,如下所示:
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'
如果我想,我甚至可以将表值函数与另一个表连接起来。
这似乎比使用存储过程更优雅,并且看起来效果会更好 - 因为它不必将结果假脱机到临时表。
为什么我最好使用存储过程来完成这些类型的任务而不是使用表值函数?有什么重要的理由吗?
答案 0 :(得分:2)
您的FindTop1000Customers过程可以在单个SELECT语句中表示吗?如果是这样,内联表值函数可能是一个很好的替代品。将State ='VIC'标准下推到基表,查询可以更快地执行。
如果不是,在应用WHERE子句之前,多语句表值函数仍需要实现完整的结果集。要将过滤器向下推到基表,您需要参数化该函数,就像存储过程一样。而且你会失去很多编程能力(临时表,动态SQL等)。
我建议Erland Sommarskog关于How to Share Data Between Stored Procedures,Dynamic Search Conditions和Dynamic SQL的文章有关此主题的更多想法。
答案 1 :(得分:1)
一般来说,对于不适用于存储过程的函数存在限制。请参阅User-Defined Function Design Guidelines。
答案 2 :(得分:1)
内联表值函数等同于参数化视图,并且它们可以作为一种强制数据库逻辑的方法而不会产生太多损失,因为优化器可以像视图一样内联扩展它们。内联TVF必须明确内联所有逻辑,因此你可以做的事情有限。
另一方面,多行表值函数具有更大的灵活性,但它的特性与存储过程可能需要仔细权衡。
在您的情况下,如果您可以使用常规视图或内联TVF进行此操作,我会先执行此操作。