SQL:避免硬编码或魔数(Magic Number)

Question

问题:在 SQL 脚本或存储过程中避免魔数(Magic Number)或硬编码值的其他策略是什么？

考虑一个存储过程，它的工作是根据记录的StatusID 检查/更新记录的值。或其他一些 FK 查找表或值范围。

考虑 Status ID 最重要的表，因为它是另一个表的 FK:



要避免的 SQL 脚本类似于:

DECLARE  @ACKNOWLEDGED tinyint

SELECT  @ACKNOWLEDGED = 3   --hardcoded BAD

UPDATE  SomeTable
SET     CurrentStatusID = @ACKNOWLEDGED
WHERE   ID = @SomeID

这里的问题是这不是可移植的，并且显式依赖于硬编码的值。将其部署到另一个没有身份插入的环境时，存在细微的缺陷。

还试图避免 SELECT基于状态的文本描述/名称:

UPDATE  SomeTable
SET     CurrentStatusID = (SELECT ID FROM [Status] WHERE [Name] = 'Acknowledged')
WHERE   ID = @SomeID

问题:在 SQL 脚本或存储过程中避免魔数(Magic Number)或硬编码值的其他策略是什么？

关于如何实现这一点的其他一些想法:

添加一个新的bit列(命名为“IsAcknowledged”)和规则集，其中只能有一个值为 1 的行.这将有助于找到唯一的行:SELECT ID FROM [Status] WHERE [IsAcknowledged] = 1)

Answer 1

对于像您的状态表这样的情况，我创建了我所谓的“静态”数据集。这些表包含的数据

在创建时设置和定义，

永不改变，

从数据库实例到数据库实例总是一样的，没有异常(exception)

也就是说，在您创建表的同时，您也可以使用脚本来填充它，以确保值始终相同。此后，无论数据库何时何地，您都将知道值是什么，并且可以相应地适本地进行硬编码。 (在这些情况下，我永远不会使用代理键或标识列属性。)

您不必使用数字，您可以使用字符串——或二进制文件或日期，或任何最简单、最容易和最合适的东西。 (如果可以的话，我会使用 char 字符串——而不是 varchars——比如“RCVD”、“DLVR”、ACKN”等等，这些是比 0、2 和 3 更容易的硬编码值。)

该系统适用于不可扩展的值集。如果可以修改这些值(这样 0 不再意味着“已确认”，那么您就有安全访问问题。如果您有一个用户可以添加新代码的系统，那么您有一个不同且棘手的设计问题需要解决.