数据库设计：多个潜在标识符答案

【问题标题】：Database design: multiple potential identifiers数据库设计：多个潜在标识符
【发布时间】：2012-02-23 14:31:35
【问题描述】：

在创建Funds 或Assets 表时，我经常遇到同样的问题：并非所有Assets 都有相同的标识符。

例如：70% 拥有ISIN，有些拥有彭博代码，有些拥有两者，有些只有来自本地会计软件包的AccountingID，等等。

通常我最终会为该表提供一个代理 PK，以及所有可能标识符的不同字段 (Bloomberg, ISIN, AccoutingID,..)

我曾经继承过这样一个数据库，其中开发人员将备用键迁移到子表 [Identifiers]，因为他事先并不知道每个可能的备用键。

这个标识符表如下所示：

什么是最好的解决方案？

我认为第一个（单表）是最好的，因为即使我冒着有几个 Null 的风险，ISIN 也是一个 ISIN，并且是 Fund 的明确定义的属性。

【问题讨论】：

【解决方案1】：

这在一定程度上取决于您的需求，但第二种方法通常更灵活，因为您可以提供一个合理的接口来插入不需要更改数据库架构的新“标识符”记录。

如果您不知道可能存在多少标识符，或者如果您知道随着时间的推移需要添加更多标识符，通常会使用此方法。

前一种方法在编写查询方面更简单，如果标识符是静态的，可能最容易使用。

【讨论】：

+1 用于将来的校对。我从不相信外部标识符作为主键。如果其他人可以控制它们，那么他们就没有动力通过不理会这些值来保持您的系统稳定。隔离多个外部标识符可以轻松、一致地检索，同时保持灵活以应对未来的变化。
是的，我完全同意，通过将标识符与相关实体一起描述的非规范化类型可能只有在您知道它不会改变或与实体的单一关系时才应该使用。
@Joel Brown：解决方案 1（单表）并不意味着使用外部标识符作为 PK ！我提到过使用代理 PK。
@iDevlop - 明白了，但是让外部标识符像 PK 一样冒险的事情 - 你无法控制它们 - 使它们作为实体的专用属性也有风险。这就是为什么像你这样的情况，有多个基于外部标识符的候选键让我觉得是 EAV 的一个很好的候选者。

【解决方案2】：

我会做单表，因为标识符表方法对 idValue 的数据类型做出假设。如果你得到一些使用 guid 而不是 int 的新东西怎么办？

您仍然可以为每个可能的资产 ID 创建一个单独的列，并将有关资产的数据保存在一个单独的表中，该表以代理 ID 为关键字。您采用的方法主要取决于您将如何使用数据，以及添加新资产 ID 类型的频率。

【讨论】：