场景：单个类型的多个类型;一对多。 例如：
父母多种类型：学生表，供应商表，客户表，酒店表
儿童单身类型：银行业务详情
因此，学生可能有多个银行详细信息，供应商等也可以。
布局选项1 学生表（id）+ students_banking_details（student_id）表具有相应的ID关系，重复每个父类型。
布局选项2 学生表（+其他）+ banking_details表。 banking_details将有一个parent_id列用于链接，parent_type字段用于确定父级是什么（学生/供应商/客户等）。
布局选项3 学生表（+其他）+ banking_details表。然后我将为每个父类型创建另一个关联表（例如：students_banking_details），用于链接student_id和banking_details_id。
布局选项4 学生表（+其他）+ banking_details表。 banking_details将为每个父类型提供一个列，即：student_id，supplier_id，customers_id - 等。
其他？您的意见......
我对以下各方的看法：
- 相同类型信息的多个表似乎有误。如果我想更改存储有关银行业务详细信息的内容，那么我还需要更改几个表而不是一个。
- 似乎是最可行的选择。显然，这并不能保持“参照完整性”。虽然。如果我在删除父母时以编程方式清理孩子，我不知道对我来说有多重要吗？
- 与（2）相同，除了每种类型有一个额外的表格，所以我的逻辑告诉我，这将比（2）更多表格和结果更慢。
- 在banking_details表中有一堆空字段，似乎很脏。
答案 0 :(得分：1)
在进一步说明之前：如果您确定了存储缺乏参照完整性的银行业务细节的设计，请告诉我谁将会运行它，以便我永远不会与他们做生意。这很重要。应遵循应用程序逻辑中的约束;事情发生，例外，中断，不一致，后来反映在数据中，因为没有有意义的保障措施。必须遵循架构设计中的约束。更安全，银行数据尽可能安全。
您将＃1识别为次优是正确的;帐户是一个帐户，无论谁拥有它。 ＃2是因为参照完整性是不可协商的。严格来说，＃3是最可行的方法，但如果你知道你永远不需要担心扩大可能有银行细节的实体数量，你就可以逃脱使用＃4和CHECK约束来确保每行只有一个一个的四个外键的值 - 但是你使用的是MySQL，它会忽略{{1约束，所以请使用＃3。
索引您的外键并且性能会很好。如果您需要这样做，可以避免样板CHECK。