代码之家 › 专栏 › 技术社区 › SupaMonkey

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

relational-database database-design database mysql

SupaMonkey · 技术社区 · 7 年前

场景:多个类型转换为单个类型;一对多。例如:

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

子单类型:银行详细信息

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

布局选项1 students表(id)+students\u banking\u details(student\u id)表,具有适当的id关系,按父类型重复。

布局选项2 学生表(+其他)+banking\u details表。banking\u details将有一个用于链接的parent\u id列和一个parent\u type字段,用于确定父项是什么(学生/供应商/客户等)。

布局选项3 学生表(+其他)+banking\u details表。然后,我将根据父类型(例如:students\u banking\u details)创建另一个关联表,用于链接student\u id和banking\u details\u id。

布局选项4 学生表(+其他)+banking\u details表。banking\u details将为每种父类型设置一列,即:student\u id、supplier\u id、customers\u id-等。

另外您的输入。。。

我对其中每一项的想法:

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

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

与(2)相同,只是每个类型有一个额外的表,所以我的逻辑告诉我,如果有更多的表和相同的结果,这将比(2)慢。

banking\u details表中有一堆空字段,这对我来说似乎很脏。

1 回复 | 直到 7 年前

dmfay 7 年前

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

您将#1确定为次优是正确的;帐户就是一个帐户,无论是谁拥有它#2被淘汰,因为引用完整性是不可协商的#严格来说,3是最可行的方法知道您无需担心可能拥有银行详细信息的实体数量的增加,您可以不必担心4个和 CHECK 约束,以确保每行只有一但您使用的是MySQL,它忽略了 检查 约束,请使用#3。

索引外键,性能就会很好。视图很好,可以避免样板文件 JOIN 如果你需要的话。