我的一位同事设计了一个表模式，在其中一个表中，列可以引用不同表中的主键取决于另一列的值。我知道这是不同的错误，但找不到支持我的理论。他的架构是这样的：
table video: (id, name, ...)
table audio:(id, name, ...)
table review_item( item_type, item_id, reason, ...)
当item_type='V', 那么 item_id 是表视频的 id 并且item_type='A'当然后 item_id 是表视频的 id
( item_type, item_id) 的组合是唯一的，但实际上它根本不是外键，你不能将它定义为外键，因为它不指向单个表。DDL 语法不允许这样做。
有人可以找出这里违反了哪些原则或规则吗？
它会起作用，但它指出了其他可能的错误。我可以想到更糟糕的设计。执行完整性将是粗暴的。
您当然可以加入，但需要在“位置”中添加一个额外条件来限制 item_type。
这种类型的排列可能表明音频和视频表应该是一个表，其他列区分音频/视频，如果您遇到这种情况，1-1 链接到纯音频或纯视频信息。但似乎很多相同的信息 - 在现实世界中 - 适用于两者。事实上，除非它是一部无声电影，否则视频表是否必须包含所有音频信息:-) ??? 如果只有一个适用，则输入空值。
如果您可以使用 oo-db，这将很容易，对吧？j/k...
显然，这是错误的。您可以声称它违反了“单一责任原则”；即事物应该有一个特定的、明确的目的。但是请通过示例清楚地说明这是多么糟糕（不要只陈述术语/短语并期望它足够好）。
我遇到的主要问题是，我认为数据库不能在这样的基础上强制执行外键约束（也许可以通过一些自定义规则）。即在 MS SQL 中，您不能引用其他表的主键并让它强制执行它，并且鉴于完整性 - 即约束的强制执行 - 是 FK 的主要好处之一，这将是我的主要论点。根据您的 OR/Mapper 的操作方式（如果您使用一个），我也会提出这一点。这可能不支持他采取的策略。
请参阅此示例，了解如何在这种情况下强制执行外键：http: //consultingblogs.emc.com/davidportas/archive/2007/01/08/Distributed-Keys-and-Disjoint-Subtypes.aspx
item_type 列违反了第二范式，但我认为这没关系，因为：A）您可以轻松实现 CHECK 约束，这意味着不会出现异常，B）为了强制执行非常有用的约束，一个项目不能是一个很小的代价不止一种类型。大多数 SQL DBMS 不能以声明方式强制执行该规则，除非您将类型列推送到每个表中。