SQL：避免硬编码或魔术数字

考虑存储过程,其作业是根据其StatusID或某些其他FK查找表或值范围来检查/更新记录的值.

考虑一个状态表,其中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脚本或存储过程中避免使用魔术数字或硬编码值的其他策略是什么？

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

>添加一个新的位列(命名为“IsAcknowledged”)和一组规则,其中只能有一行的值为1.这将有助于查找唯一的行：SELECT ID FROM [Status] WHERE [IsAcknowledged] = 1)

解决方法

>使代码更易于阅读(即说“确认”而不是3可能会使您的意图对读者更为明显.
>使代码更加动态,一个函数可以使用参数,而不是几个函数(这不是一个简化,但是这个意思应该是相当不言而喻的)

为各州制定一列可能是一个好的或坏的主意;它真的只取决于数据.如果数据经历了各种“阶段”(收到,确认,审核,拒绝,接受,回复等),那么这种方法可以快速地将自身摆脱生存能力(更不用说必须确保只有一个列在任何给定的时间被设置为1).另一方面,如果状态真的像您所描述的那样简单,那么这样做可以使代码更易读,索引性能更好.

硬编码值中最大的no-no是引用其他实体的硬编码值(换句话说,硬编码相应对象的主键).字符串“已确认”仍然是一个硬编码的值,它的意义更为透明,而不是对其他内容的引用.对我来说,它归结为：如果你能(合理地)查找它,做它.如果你不能(或者某些东西使它成为一个不合理的任务,从性能或可维护性的角度),硬编码.使用这个,你可以通过使用Acknowledged来查找3的值;你不能抬头从其他的东西确认.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!