SQL Server：内联表值 UDF 与内联视图

Question

我正在使用一个医疗记录系统，该系统将数据存储在一个类似于电子表格的结构中——列标题中的日期/时间，每行第一列中的测量值（例如医生姓名、Rh、血型），和相交单元格中的值。基于此构造的报告通常需要显示 10 个或更多这些度量。

出于报告目的，数据集需要为每位患者提供一行、进行测量的日期/时间以及每次测量的一列。本质上，需要将结构旋转 90 度。

有一次，我实际上使用 SQL Server 的 PIVOT 功能来做到这一点。由于各种原因，这种方法显然行不通。我决定使用内联视图 (IV) 将数据转换为所需的格式。简化的查询类似于：

SELECT patient_id, 
       datetime, 
       m1.value AS physician_name, 
       m2.value AS blood_type, 
       m3.value AS rh
  FROM patient_table
INNER JOIN ( complex query here
              WHERE measure_id=1) m1...
INNER JOIN (complex query here
              WHERE measure_id=2) m2...
LEFT OUTER JOIN (complex query here
                 WHERE measure_id=3) m3...

如您所见，在某些情况下，这些 IV 用于限制结果数据集（INNER JOIN），在其他情况下，它们不限制数据集（LEFT OUTER JOIN）。但是，除了 measure_id 不同之外，每个度量的“复杂查询”部分基本相同。虽然这种方法有效，但它会导致相当大的 SQL 语句，限制重用，并使查询容易出错。

我的想法是用内联表值 UDF 替换“复杂查询”和 WHERE 子句。这将大大简化查询，减少错误并增加代码重用。我心中唯一的问题是性能。 UDF 方法会导致性能显着下降吗？它可能会改善问题吗？

感谢您的时间和考虑。

Answer 1

正确定义的 TVF 不会带来任何问题。与视图或临时表和变量相比，您会发现许多关于实习爆破 TVF 的性能问题的声明。通常不理解的是 TVF 的行为与视图不同。视图定义被放入原始查询中，然后优化器将重新排列它认为合适的查询树（除非在索引视图上使用 NOEXPAND 子句）。 TVF 具有不同的语义，有时，特别是在更新数据时，这会导致 TVF 输出为haloween protection 假脱机。它有助于标记函数WITH SCHEMABINDING，参见Improving query plans with the SCHEMABINDING option on T-SQL UDFs。

理解确定性和精确函数的概念也很重要。尽管它们主要适用于标量值函数，但 TVF 也会受到影响。见User-Defined Function Design Guidelines。

Answer 2

由于您需要 SQL 字符串并且可能无法向系统添加视图或 UDF，因此您可能希望使用 WITH ... AS 将复杂查询限制在一个位置（至少对于此语句。 )。

WITH complex(patientid, datetime, measure_id, value) AS
(Select... Complex Query)
SELECT patient_id
,        datetime
,        m1.value AS physician_name
,        m2.value AS blood_type
,        m3.value AS rh  
FROM patient_table
INNER JOIN (Select ,,,, From complex WHERE measure_id=1) m1...
INNER JOIN (Select ,,,, From complex WHERE measure_id=2) m2...
LEFT OUTER JOIN (Select ,,,, From complex WHERE measure_id=3) m3...

Answer 3

Sql Server 2005 答案： 您可以使用 temp/var 表来减少内联视图。这些性能问题是查询每次命中所需的临时插入，但如果结果集足够小，它们会有所帮助。您可以在 var 表上使用主键，在临时表上使用主键/索引。除了正常的相信之外，我发现了几篇文章表明两个 temp/var 表都存储在 temp db 中。

UDF 函数，我们发现在复杂查询中有多层 udf 时性能较差，但会保持可用性。 确保为指定的各种条件正确创建函数。将用于内连接的那些，以及将用于左连接的那些。

所以，一般来说。我们确实使用 UDF，但是当我们发现性能下降时，我们会移动查询以将 UDF 选择插入到 temp/var 表中并加入这些表。

创建易于使用/维护的功能，并在需要的地方和时间应用性能增强。

编辑：

如果你需要为 Crystal 运行这个，并且你打算使用存储过程，是的，你可以在 SP 中执行 sql 语句到 temp/var 表。

如果您要使用 SP，请告诉我。然后，Sql 还将根据需要缓存具有给定参数的 sp 计划。

同样从之前使用水晶的经验来看，要避免的事情是在水晶中进行分组，可以在 SP 中完成，如果不需要，页码。和函数调用，如果这可以在服务器上处理。

Answer 4

您还有第三种选择；传统的 VIEW（假设您有一个要加入的密钥）。理论上，这三个选项之间不应该存在性能差异，因为 SQL Server 应该相应地评估和优化计划。现实情况是，有时情况并不像我们希望的那样发生。

传统视图的好处是您可以将其设为索引视图，并为 SQL Server 提供另一种性能辅助；但是，您只需要测试并查看即可。