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

Question

场景:多种类型转单一类型；一对多。例如:

父级多种类型:学生表、供应商表、客户表、酒店表

child 单一类型:银行详细信息

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

布局选项 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 - 等。

其他？您的意见...

My thoughts on each of these:

1. Multiple tables of the same type of information seems wrong. If I want to change what gets stored about banking details, thats also several tables I have to change as opposed to one.
2. Seems like the most viable option. Apparently this doesnt maintain 'referential integrity' though. I don't know how important that is to me if I'm just going to be cleaning up children programatically when I delete the parents?
3. Same as (2) except with an extra table per type so my logic tells me this would be slower than (2) with more tables and with the same outcome.
4. Seems dirty to me with a bunch of null fields in the banking_details table.

Answer 1

在继续之前:如果您确实决定采用一种缺乏引用完整性的存储银行详细信息的设计，请告诉我谁将运行它，这样我就永远无法与他们开展业务。就是这么重要。 可以遵循应用程序逻辑中的约束；事情发生、异常、中断、不一致，这些都会随后反射(reflect)在数据中，因为没有有意义的保障措施。必须遵循架构设计中的约束。。安全得多，银行数据应该尽可能安全。

您将 #1 确定为次优是正确的；帐户就是帐户，无论谁拥有它。 #2 已被淘汰，因为参照完整性是不可协商的。严格来说，#3 是最可行的方法，尽管如果您知道，您永远不需要担心增加可能拥有银行详细信息的实体数量，那么您可以采用# 4 和一个 CHECK 约束，以确保每行仅具有四个外键中一个的值 - 但您使用的是 MySQL，它会忽略 CHECK 约束，所以选择#3。

索引你的外键并且性能会很好。如果您需要这样做， View 可以很好地避免样板 JOIN。