考虑以下两个表：
Table A: [K1, K2, PropA]
Table B: [K3, PropB]
表 A 的主键是复合的[K1,K2]。表 B 的主键是K3.
表对表 B 的值具有包容性依赖关系，K3必须与 K2 中的值匹配。不幸的是，由于K2不是唯一的主键，我无法在这些列上定义外键约束。
正如我所看到的，解决方案是在应用程序层中强制执行它，或者将该K1列传播到表 B，以便它将包含表 A 的整个外键。
我的问题：这在数据库设计中被认为是好的还是坏的做法？假设从维护角度或完整性角度来看，添加额外的列不是问题（插入是事务性的）。
我正在使用 MSSQL 和 Oracle。
创建表 C，只有一个属性 K2，它是主键。现在您可以使用外键约束来引用 K2。
将 K1 属性放入表 B 中可能是个坏主意。如果我理解正确的话，看起来它会创建违反 2NF 的非键依赖关系。
您的问题确实提出了一个重要观点：现代数据库软件中对数据完整性约束的支持通常很差，这意味着数据库设计人员有时不得不做出一些尴尬的妥协。
“......解决方案是在应用层强制执行或传播......”
你看对还是看错，取决于视角。
真正的解决方案是让 DBMS 供应商支持包含依赖的一般情况，其中外键只是一种特殊情况。
但是只要 DBMS 供应商不这样做，你就是对的，只要你一直限制自己对这些供应商的产品，你将别无选择，只能将约束实施转移到应用程序 [*]，或者用你需要的所有那些丑陋的黑客来搞砸设计，以便只使用 FK 来强制执行你的约束。
Shark.armchair.mb.ca/~erwin 为您提供了一个既不涉及“在应用程序中执行”也不涉及“搞砸设计”的解决方案的系统。披露：该项目是我自己制作的。
[*] 或将所有约束执行代码放在触发器中，这样至少新应用程序不会“忘记”执行某些给定的现有业务规则。