Question

使用make函数（缩放器和表值）比使用多个表一次又一次的复杂连接是一个好习惯。例如

案例1：

SELECT 
*
FROM table1 t1
INNER JOIN table2 t2 ON t1.ID=t2.ID
INNER JOIN table2 t3 ON t2.ID=t3.ID
INNER JOIN table2 t4 ON t3.ID=t4.ID
INNER JOIN table2 t5 ON t4.ID=t5.ID
INNER JOIN table2 t6 ON t5.ID=t6.ID
INNER JOIN table2 t7 ON t6.ID=t7.ID

案例2

SELECT *
FROM table1 t1
INNER JOIN udf_myFunc() udf ON udf.ID=t1.ID

是否存在一种方法具有明确优势的情况？

Answer 1

为了便于阅读，＃1更好 - 它清楚对象在做什么，即使它更详细。

为了重复使用，＃2更好 - 特别是如果您看到逻辑可能会在多个电话中发生变化，最好只在一个地方进行更改。

我想这取决于你的目标是什么。我通常选择可读性而不是重复使用。

Answer 2

没有。

如果要隐藏/管理复杂性并启用重复使用，请使用“查看”
使用联接中的UDF
您可能希望设置索引视图 - 这可能会带来更好的性能
在MS SQL中难以组织和管理UDF。过度依赖它们很快就会陷入混乱的UDF

Answer 3

取决于。

与连接相比，多语句表值函数是一种性能杀手。它无法解开并集成到查询中。在apply中使用时特别糟糕。
然而，有时候这是一个好处，因为一个结果相同的联接是一场噩梦。
内联表值函数很好。服务器可以将其展开并集成到查询中。性能没有差异，执行计划与连接相同 因此，在不降低性能的情况下封装某些逻辑可能是一个不错的选择。
标量函数大部分都是正常的，除了查询优化器做了奇怪的事情并开始调用它的次数超过实际应用的情况。在这种情况下，可以将这样的函数重写为表值函数，该函数返回一行包含一列并将其作为表连接，而不是使用where条件中的值。
但是否则也没关系。

Answer 4

我必须投票反对功能方向。如果没有其他原因，它会混淆意图。此外，如果您重复使用它可能会节省一些工作，但这是唯一可能的好处，因为它不会提高性能。

当你必须按摩某个特定的数据时，我喜欢函数，但是使用一个来避免连接是处理事情的一种讨厌的方法。

函数与SQL中的复杂连接

4 个答案: