i_a*_*ero 3 database-design join foreign-keys self-join
我需要数据库设计专家提出一些建议.
我有大约六个外键到一个表(缺陷),它都指向用户表中的主键.它像是:
defect (.....,assigned_to,created_by,updated_by,closed_by...)
Run Code Online (Sandbox Code Playgroud)
如果我想获得有关缺陷的信息,我可以进行六次连接.我们有更好的方法吗?
另一个是我有一个states表可以存储一个用户定义的值.我有缺陷表和任务表,我希望这两个表共享公共状态表(New,In Progress等).所以我创建了:
task (.....,state_id,imp_id,.....)defect(.....,state_id,imp_id,...)state(state_id,state_name,...)importance(imp_id,imp_name,...)有许多这样的共同属性以及状态如重要性(正常,紧急等),优先级等.对于所有这些,我想使用相同的表.我在每个表中保留一个标志以区分任务和缺陷.在这种情况下,最佳解决方案是什么?
如果有人在健康域中使用此应用程序,他们希望为其缺陷或任务分配不同的类型,状态,重要性.此外,当用户选择任何项目时,我想在配置参数部分下显示所有类型,状态等.
1 ...
这没有什么本质上的错误.如果可能的用户"角色"是严格确定的并且不太可能改变,那么这实际上是这样做的首选方式.您正在有效地建模C:M关系,其中C是常量.
另一方面,如果角色可以改变(例如,您需要能够动态地向缺陷添加新的"生命周期阶段"),那么建立真正的M:N关系的链接(也称为联结)表可能会是有道理的.像这样的东西:

顺便说一句,虽然JOIN有他们的成本,但这本身并不意味着你买不起.而且你甚至可能都不需要所有的JOIN - 只需要做一些带来你当前需要的信息的JOIN并将其他人留下来.无论如何,我建议您测量实际数据量,以确定是否存在实际性能问题.
2 ......
如果有许多公共字段,则可以使用继承1来最小化公共字段和外键的重复.例如:

在这个模型中,每个"属性"表(例如state和importance)只与base它连接一次,并通过它连接到每个"继承"表,例如defect和task.无论您添加多少"继承"表,每个"属性"表仍然只有一个连接
该模型基本上防止"属性" FKS增殖,为稍微更麻烦的管理的价格defects和tasks(因为它们现在被划分到"公共"和"特定的"部分).这是否比旧设计更好的平衡是你决定...
1阿卡.类别,子类,泛化层次等...