在处理查找表和相关业务逻辑时去掉硬编码值

Mik*_*ika 5 sql sql-server database-design business-logic

示例案例:

我们正在使用SQL Server构建租赁服务.有关可以租借的项目的信息存储在表格中.每个项目的状态可以是"可用","已租用"或"已损坏".不同的状态驻留在查找表中.

ItemState表:

ID名称
1"有空"
2"租用"
3"断"

除此之外,我们还有一个业务规则,规定每当返回一个项目时,它的状态将从"已租用"更改为"可用".
这可以通过更新语句来完成,例如"update Items set state = 1 where id = @ itemid".在应用程序代码中,我们可能有一个映射到ItemState id:s的枚举.但是,这些包含可能导致以后出现维护问题的硬编码值.假如开发人员要更改状态集但忘记修复相关的业务逻辑层...

有哪些好的方法或替代设计可以解决这类设计问题?
除了直接答案之外,还了解相关文章的链接.

Otá*_*cio 5

以我的经验,这是您实际上必须进行硬编码的情况,最好使用一个枚举,该整数与查找表的ID相匹配。说“ 1”始终是“可用”,我没有发现任何错误。


小智 2

当您在代码中定义了查找表和枚举时,您总是会遇到保持它们同步的问题。这里无能为力。两者都有效地生活在两个不同的世界中,并且通常彼此不了解。

您可能希望拒绝使用查找表,而只让您的业务逻辑操作这些值。在这种情况下,您将错过依靠引用完整性来支持数据完整性的选项。

另一种选择是以您在代码中永远不需要这些值的方式构建应用程序。这意味着将部分业务逻辑移动到数据库层,也就是说,将它们放入存储过程和触发器中。这还有一个好处是对客户来说是不可知的。任何人都可以调用 SP 并确保数据将保持一致状态,也与您的业务逻辑规则一致。