sql-server - SQL 中常量的最佳模式？

Question

我见过几种用于“克服”SQL Server 中常量缺乏的模式，但它们似乎都不能同时满足性能和可读性/可维护性问题。

在下面的示例中，假设我们的表上有一个完整的“状态”分类，选项似乎是:

• 只是对其进行硬编码，并且可能只是“评论”状态

-- StatusId 87 = Loaded
SELECT ... FROM [Table] WHERE StatusId = 87;

• 使用状态查找表，然后连接到该表，以便 WHERE 子句引用友好名称。

子查询:

SELECT ... 
FROM [Table] 
WHERE 
  StatusId = (SELECT StatusId FROM TableStatus WHERE StatusName = 'Loaded');

或加入

SELECT ... 
FROM [Table] t INNER JOIN TableStatus ts On t.StatusId = ts.StatusId 
WHERE ts.StatusName = 'Loaded';

• 定义了一堆标量 UDF，它们返回常量，即

CREATE Function LoadedStatus()
RETURNS INT
AS
 BEGIN
  RETURN 87
 END;

然后

SELECT ... FROM [Table] WHERE StatusId = LoadedStatus();

(IMO 这会对数据库造成大量污染 - 这在 Oracle 包包装器中可能没问题)

• 与表值函数类似的模式将常量作为行或列保存，这些常量CROSS APPLIED返回到[Table]

其他 SO 用户是如何解决这个常见问题的？

编辑:赏金 - 有没有人有根据 Remus 回答和评论在 DBProj DDL/Schema 脚本中维护 $(变量) 的最佳实践方法？

Answer 1

硬编码。对于 SQL，性能胜过可维护性。

使用优化器可以在计划生成时检查的常量与使用任何形式的间接(UDF、JOIN、子查询)之间的执行计划后果通常是巨大的。 SQL“编译”是一个非凡的过程(在某种意义上，它不像 IL 代码生成那样“普通”)，因为结果不仅取决于正在编译的语言结构(即查询的实际文本)，还取决于由数据模式(现有索引)和这些索引中的实际数据(统计数据)组成。当使用硬编码值时，优化器可以给出更好的计划，因为它实际上可以根据索引统计信息检查该值并获得结果的估计。

另一个考虑因素是 SQL 应用程序不仅仅是代码，而且很大程度上是代码和数据。 “重构”SQL 程序是……不同的。在 C# 程序中，我们可以更改常量或枚举、重新编译并愉快地运行应用程序，但在 SQL 中则不能这样做，因为该值可能存在于数据库中的数百万条记录中，并且更改常量值意味着也更改 GB 数据，在新操作发生时经常在线。

仅仅因为该值在服务器看到的查询和过程中被硬编码，并不一定意味着该值必须在原始项目源代码中硬编码。有各种代码生成工具可以解决这个问题。考虑像利用sqlcmd scripting variables这样微不足道的事情:

defines.sql:

:setvar STATUS_LOADED 87

somesource.sql:

:r defines.sql
SELECT ... FROM [Table] WHERE StatusId = $(STATUS_LOADED);

someothersource.sql:

:r defines.sql
UPDATE [Table] SET StatusId = $(STATUS_LOADED) WHERE ...;