我正在使用一个医疗记录系统，该系统将数据存储在类似于电子表格的结构中——列标题中的日期/时间，每行第一列中的测量值（例如医生姓名、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方法会导致性能显着下降吗？它可能会改善情况吗？
感谢您的时间和考虑。
正确定义的 TVF 不会引入任何问题。与视图或临时表和变量相比，您会发现许多关于暂存爆破 TVF 性能问题的声明。通常不被理解的是 TVF 的行为与视图不同。视图定义被放入原始查询中，然后优化器将根据需要重新排列查询树（除非在索引视图上使用 NOEXPAND 子句）。 TVF 具有不同的语义，有时，特别是在更新数据时，这会导致 TVF 输出被假脱机处理万圣节保护 http://www.mcjones.org/System_R/SQL_Reunion_95/sqlr95-System.html#Index197。它有助于标记功能WITH SCHEMABINDING, see 使用 T-SQL UDF 上的 SCHEMABINDING 选项改进查询计划 http://blogs.msdn.com/sqlprogrammability/archive/2006/05/12/596424.aspx.
理解确定性函数和精确函数的概念也很重要。尽管它们主要适用于标量值函数，但 TVF 也会受到影响。看用户定义函数设计指南 http://msdn.microsoft.com/en-us/library/ms187440.aspx.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
