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

Question

场景：多种类型转换为一种类型；一对多。 比如：

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

子单类型：银行明细

所以一个学生可能有多个银行详细信息，供应商等也可以。

布局选项 1 学生表 (id) + students_banking_details (student_id) 表，具有适当的 id 关系，每个父类型重复。

布局选项 2 学生表（+其他）+banking_details 表。 bank_details 将有一个用于链接的 parent_id 列和一个用于确定父级（学生/供应商/客户等）的 parent_type 字段。

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

布局选项 4 学生表（+其他）+banking_details 表。 bank_details 将为每个父类型提供一个列，即：student_id、supplier_id、customers_id 等。

其他？您的意见...

我对这些的想法：

1. 相同类型信息的多个表似乎错误。如果我想更改有关银行详细信息的存储内容，我还必须更改几张表，而不是一张。
2. 似乎是最可行的选择。显然，这并不能保持“参照完整性”。如果我只是在删除父母时以编程方式清理孩子，我不知道这对我有多重要？
3. 与 (2) 相同，但每种类型都有一个额外的表，因此我的逻辑告诉我，这将比 (2) 慢，但具有更多表且结果相同。
4. banking_details 表中有一堆空字段对我来说似乎很脏。

Answer 1

在继续之前：如果您决定存储缺乏参照完整性的银行详细信息的设计，请告诉我将由谁来运行它，这样我就永远无法与他们做生意。这很重要。您的应用程序逻辑中的约束可能会被遵循；事情发生、异常、中断、不一致，这些后来反映在数据中，因为没有有意义的保护措施。 必须遵循架构设计中的约束。安全得多，银行数据也尽可能安全。

您将 #1 确定为次优是正确的；一个账户就是一个账户，无论谁拥有它。 #2 被淘汰了，因为参照完整性是不可协商的。严格来说，#3 是最可行的方法，尽管如果您知道您永远不需要担心扩大可能拥有银行详细信息的实体的数量，您可以侥幸逃脱 # 4 和 CHECK 约束，以确保每一行只有四个外键中的 一个 的值——但您使用的是忽略 CHECK 约束的 MySQL，所以使用 # 3.

索引您的外键和性能会很好。如果您有需要，可以避免使用样板代码 JOINs 来查看视图。