MySQL数据库布局/建模/设计方法/关系

场景：从多个类型到单个类型；一对多。 例如：

父多类型：学生表、供应商表、客户表、酒店表

子单类型：银行详细信息

因此，一名学生可能有多个银行详细信息，供应商等也可能有

布局选项1学生表（id）+具有适当id关系的学生银行详细信息（学生id）表，按家长类型重复

布局选项2学生表（+其他）+银行详细信息表。银行详细信息将有一个用于链接的父项id列和一个用于确定父项是什么（学生/供应商/客户等）的父项类型字段

布局选项3学生表（+其他）+银行详细信息表。然后，我将为每个父类型（例如：students_banking_details）创建另一个关联表，用于链接student_id和banking_details_id

布局选项4学生表（+其他）+银行详细信息表。银行详细信息将针对每种父类型有一列，即：学生id、供应商id、客户id-等等

其他？您的输入

我对这些问题的看法如下：

相同类型信息的多个表似乎是错误的。如果我想更改存储的关于银行详细信息的内容，我还必须更改几个表，而不是一个表

似乎是最可行的选择。显然，这并不能保持“引用完整性”。我不知道这对我来说有多重要，如果我只是想在删除父母的时候按程序清理孩子

与（2）相同，只是每个类型都有一个额外的表，所以我的逻辑告诉我，这将比（2）有更多的表和相同的结果要慢

在我看来，在banking_details表中有一堆空字段是肮脏的

---

在进一步讨论之前：如果您确实决定了一种存储银行详细信息的设计，而这种设计缺乏参考完整性，请告诉我谁将运行它，这样我就永远无法与他们做生意。这很重要。可以遵循应用程序逻辑中的约束；事情发生了，异常，中断，不一致，这些后来会反映在数据中，因为没有有意义的保护措施。必须遵循模式设计中的约束。更安全，银行数据是尽可能安全的

你认为1次优是正确的；帐户就是一个帐户，不管是谁拥有它#2被排除，因为引用完整性是不可协商的#严格来说，3是最可行的方法，尽管如果你知道你永远不需要担心增加可能拥有银行详细信息的实体的数量，你可以不使用#4和

检查
约束来确保每一行只有四个外键中的一个的值，但是你使用的是MySQL，它忽略了
检查
约束，因此使用#3

索引外键，性能就会很好。如果需要，视图可以避免使用样板文件
JOIN
s。
感谢您的输入。顺便说一句，这不是一个真实的例子——只是为了讨论：）