ViewModel中的代理键而不是主键

时间:2017-05-29 13:07:05

标签: database-design primary-key viewmodel software-design surrogate-key

最佳做法是如何防止在ViewModel中显示来自数据库的自动增量主键(ID' s),以使其对最终用户不可见?

我知道桌子上可以有其他独特的字段,可以使用。但是,如果它不确定是否存在(或将保留)一个独特的呢?

我正在考虑创建一个哈希并将其保存在数据库中名为ViewKey的列中。例如在表格地址中。

2 个答案:

答案 0 :(得分:0)

最佳做法是,您需要对用户可见并且在业务域中有意义且可用的密钥(通常称为业务密钥自然密钥)。如果您没有实现这些密钥并使其对用户可见,那么您如何期望用户识别数据库中的信息并在现实世界中正确使用它?

密钥是否为主要密钥没有多大区别。重要的是它们是不可空的,并且在数据库中使用唯一性约束来强制执行。

如果您尚未确定合适的密钥作为分析和设计的一部分,那么请花些时间来完成。业务要求必须是决定性因素。显然没有单一的“一刀切”的解决方案。

答案 1 :(得分:0)

也许我误解了这个问题。如果您不想向最终用户显示数据库字段,那么......不要。您是否使用某种工具让最终用户直接访问您的数据库表,而您无法控制他们看到的字段?

如果您的意思是“用户如何在不使用此类自动编号字段的情况下识别记录?”如果表具有一些自然键,即存在于计算机外部的世界中的标识符,如社会安全号或标准国家代码或其他,则可以将其用作主键,并且您不需要自动编号。如果没有保证唯一的真实世界值,则必须创建标识符,例如自动编号字段或guid。如果您为内部使用创建标识符,那么您也可以向用户显示该标识符,并允许用户使用它来标识记录。除非您需要,为什么要创建“内部标识符”和“外部标识符”?如果有一些原因导致自动数字字段不可接受 - 标识符必须有校验位或某些字符 - 然后创建一个可接受的标识符并在内部和外部使用它。

有时自然键是内部键的不良选择,最常见的原因是因为它太长而且会使索引和查找变大和变慢。这是我看到有“内部密钥”和“外部密钥”的唯一原因。