用户定义的功能-它们的编码习惯不好吗？

| 我正在编写包含相当复杂的数据集和大量联接的报告。为了简化问题，并且因为我基本上是一个OO开发人员，所以我一直在编写很少的（通常是标量的）函数来完成可以通过加入子查询来完成的工作。这种事情： 
SELECT 
    x.Name, x.userId, 
    ... [more columns and joins]
    dbo.CountOrders(x.userId)
FROM Customers x 
WHERE ...
这是好习惯吗？ ？慢？我应该编写常规的T-SQL来完成这些工作吗？     
2020-01-15 4 条评论
分享

没有找到相关结果

    已邀请:

    才脊烽馈低

    我几乎永远不会拥有执行数据访问的标量UDF。 优化器无法扩展标量UDF，需要对RBAR进行评估。众所周知，这不是一个好主意。 一些示例阅读。 TSQL标量函数是邪恶的。 标量函数，内联函数和性能：无聊的帖子的有趣标题 Higly Voted Connect项目     
    2020-01-15 0 0
    分享

    葛瞎说漓

    我认为并根据我的经验，内联函数不一定是邪恶的。有时候，我面临一项不使用功能便无法完成的任务。如果要在存储过程中重复使用相同的例程，那么就像在旧的OOP中一样，您可以创建一个函数并使用它。但是，仅出于简洁简洁的代码，我不建议您使用函数（如果它是一次性的）。 性能的提高或提高来自表索引和索引维护。只要正确创建和维护索引，内联函数就和编写普通sql语句一样好。     
    2020-01-15 0 0
    分享

    赣借

    我认为在SQL中执行函数调用计算不会有太大的危害，只要可以清楚地知道表的用户在哪里进行计算即可。您在这里所做的只是为子查询创建快捷方式。但是，由于人们开始“理所当然”地进行这些类型的计算，因此我从未使用主访问查询来执行此操作。 如果我发现自己反复进行此操作，则发现制作一个包含预计算形式的此类信息的后备表，然后使用触发器使之保持最新状态会更有价值。这方面的一个示例是一个数据库，在该数据库中，我将发票行项目中的财务摘要数据汇总到报价级别，然后再汇总到提交级别（具有多个报价），然后又汇总到策略级别（具有多个报价）来自多个运营商的树）。 事实证明，大多数查询确实需要策略级别的数据。通过使用触发器和汇总表，我简单地将一些关键查询加速了两个数量级，这仅仅是因为工作已经完成，同时将已保存的更改的性能降低了很小的数量。因此，如果您发现自己做了很多汇总查询，请考虑一种避免工作的方法...但是对于简单的情况，我认为对函数的内联调用是可以的。     
    2020-01-15 0 0
    分享
    为什么被折叠? 0 个回复被折叠

    要回复问题请先登录或注册

    或代码 OrCode.com 备案号：粤ICP备15020848号-1
    Escape time: 0.044358015060425