问: 在SQL脚本或存储过程中,避免幻数或硬编码值还有哪些其他策略?
考虑一个存储过程,该存储过程的工作是根据其StatusID或某些其他FK查找表或值的范围来检查/更新记录的值。
StatusID
考虑一个Status表,其中ID最重要,因为它是另一个表的FK:
Status
应避免的SQL脚本 如下所示 :
DECLARE @ACKNOWLEDGED tinyint SELECT @ACKNOWLEDGED = 3 --hardcoded BAD UPDATE SomeTable SET CurrentStatusID = @ACKNOWLEDGED WHERE ID = @SomeID
这里的问题是,这不是可移植的,并且显式依赖于硬编码的值。在将其部署到另一个没有标识插入的环境时,存在细微的缺陷。
还尝试避免SELECT基于文本的描述/名称的状态:
SELECT
UPDATE SomeTable SET CurrentStatusID = (SELECT ID FROM [Status] WHERE [Name] = 'Acknowledged') WHERE ID = @SomeID
关于如何实现此目标的其他一些想法:
bit
1
SELECT ID FROM [Status] WHERE [IsAcknowledged] = 1)
在某种程度上,将会有一些“硬编码”的值。消除它们的想法来自两个方面:
'Acknowledged'
3
使bit列各种状态可以是好还是坏主意; 它实际上仅取决于数据。如果数据经过不同的“阶段”(收稿时承认,在审查,拒绝,接受,回应道,等),那么这种做法迅速扩展自身出活力(更何况有保证的刺激性过程 只有一个 的在任何给定时间将列设置为1)。另一方面,如果状态确实如您所描述的那样简单,则这样做可以使代码更具可读性,并且索引的性能更好。
硬编码值中最大的否定是 引用其他实体的硬编码值 (换句话说,硬编码对应对象的主键)。字符串'Acknowledged‘仍然是一个硬编码的值,它的含义更加透明,并且不是对其他内容的引用。对我来说,可以归结为: 如果可以(合理地)查找它,那就去做吧 。如果不能(或者从性能或可维护性的角度来看,使它成为不合理的任务),请对其进行硬编码。使用它,您可以使用来查找3的值Acknowledged。你不能Acknowledged从其他任何东西抬头。
'Acknowledged
Acknowledged