【发布时间】：2015-07-08 10:00:38
【问题描述】：
我知道，这已经讨论过好几次了（大多数讨论都是几年前的......）。
但是 - 通过这些讨论 - 我感觉到，有一个广泛传播的常识是完全错误的：TV-UDF 的性能很差。
很多人更喜欢 SP 来收集数据，为什么？
当我说 TV-UDF 时，我只是在说 single-statement-UDF（“Inline-UDF”）。优化器将巧妙地处理这一权利，就好像这部分是直接写入查询中一样。多语句 UDF 的性能要差得多...
在我看来，为什么您几乎应该使用 UDF 来收集数据，我看到了以下几点：
- 最佳性能（我做了很多比较！）
- 您可以轻松地将它们与 JOIN 或 APPLY 结合使用，并获得非常复杂但仍然可读的查询（我使用了一个“univers”查询，其中包含 30 多个函数和超过 1000 列 - 只需几秒钟！）
- 您可以从任何地方呼叫他们（例如，通过 ODC 一次呼叫填写 EXCEL 表）
- 您可以将它们与 XML 调用完美混合
- 如果您的选择只需要列的子集，优化器将跳过不需要的部分 - SP 则不然
- 使用 inline-UDF，优化器可以预测行数，并能够使用其所有的索引、统计功能……但 SP 不是这样
- 使用 inline-UDF，当您想在后者中使用数据时，无需为插入编写整个表定义
- 你可以用
Select count(*) from(select * from dbo.MyFunc())“包装”一个UDF来预测行数。优化器将只执行获取计数所需的部分... - 而且 - 最后但并非最不重要的一点 - 由于 UDF 从不写任何东西，它在锁定方面要轻得多
当结果在任何情况下都是一个不同的行时，我使用多语句 UDF，而当需要游标或动态 sql 时使用 SP（这种情况非常罕见）。
那么：为什么这么多人使用 SP 来收集数据？为什么这么多人认为 UDF 不好？有什么好的理由还是这只是老常识？
感谢您的意见！
【问题讨论】：
-
好的，我理解这种“搁置”是因为“主要基于意见”...但我确实喜欢技术讨论...我的问题不是“基于意见”而是不是“没有事实”......我想开始讨论是因为 - 在我看来 - 使用 SP 执行 SELECT 只是不好的做法。但我看到即使是非常有经验的开发人员也会这样，我认为，讨论可能是值得的。因此，如果您想重新开放，我很高兴...
-
既然你在别处就这个问题向我“敲门”了，我会在这里回复——这是基于意见的，在这些问题上没有明确的共识。您已经说过“我想开始讨论是因为...”但请查看What types of questions should I avoid asking?：“如果您提出问题的动机是“我想参加关于 ______ 的讨论”，那么您不应该在这里问。”
-
@Damian，好的，这可能是一般性讨论的错误地点。但仍然：SP 是一种选择数据的糟糕方式！您与 ORDER BY 的论点是错误的（顺便说一句：您可以将带有 ROW_NUMBER 的排序字段添加到您的结果集中 - 这更好。很多人这样做 - 为什么不讨论它（不是“基于意见”但有明确的论据？
标签： sql-server sql-server-2008 stored-procedures sql-server-2012 stored-functions