是否有最佳实践如何防止在 ViewModel 中显示来自数据库的自动增量主键 (ID)，以使它们对最终用户不可见？
我知道表格上可能还有其他可以使用的唯一字段。但是，如果不确定是否存在（或将保留）一个独特的，该怎么办？
我正在考虑创建一个哈希并将其保存在数据库中名为 ViewKey 的列中。例如在表地址中。
【问题讨论】：
标签： database-design primary-key viewmodel software-design surrogate-key
最佳实践是您需要对用户可见且在业务领域中有意义且可用的密钥（通常称为业务密钥或自然密钥）。如果您不实施此类密钥并使它们对用户可见，那么您如何期望用户识别数据库中的信息并在现实世界中正确使用它？
键是否是主键并没有太大区别。重要的是它们是不可为空的，并且在您的数据库中通过唯一性约束强制执行。
如果您尚未在分析和设计过程中确定合适的密钥，请花时间这样做。业务需求必须是决定性因素。显然没有一种万能的解决方案。
【讨论】：
也许我误解了这个问题。如果您不想向最终用户显示数据库字段，那么......不要。您是否正在使用某种工具让最终用户直接访问您的数据库表，而您无法控制他们看到的字段？
如果您的意思是“用户如何在不使用此类自动编号字段的情况下识别记录？”如果表有一些自然键，即存在于计算机之外的世界中的标识符，例如社会安全号码或标准国家代码或其他任何东西，那么您可以将其用作主键并且您不需要自动编号。如果没有保证唯一的真实值，那么您必须创建一个标识符，例如自动编号字段或 guid。如果您创建一个标识符供内部使用，那么您不妨将其展示给用户，并允许用户使用它来识别记录。除非需要，否则为什么要创建“内部标识符”和“外部标识符”？如果出于某种原因无法接受自动编号字段——标识符必须有校验位或类似的——然后创建一个可接受的标识符并在内部和外部使用它。
有时自然键对于内部键来说是一个糟糕的选择，最常见的原因是它太长了，它会使索引和查找变得又大又慢。这是我看到拥有“内部密钥”和“外部密钥”的唯一原因。
【讨论】：