数据库表的设计思想。。

Question

我有一个数据库结构的问题，我正在寻找一些意见。

假设有这样一个场景，用户将使用应用程序来请求材料。

有必要跟踪谁是请求者。

有三种可能的“类型”的请求者。个人(个人)、部门和供应商自己提供材料。

此外，供应商对象也需要与供应商相关。

因此，在请求表中有一个RequestedByID FK。但是，相关的请求者对于每个请求者的数据都有如此不同的结构，如果只创建一个表(人员具有不同于部门和供应商的属性)，则需要一个完全非规范化的表来进行关联。

我对如何处理这个问题有一些想法，但我认为SO社区会有一些很好的洞察力。

感谢大家的帮助。

编辑：

伪结构：

请求

RequestID RequesterID

部门

DepartmentID DepField1 DepField2

人物

PersonID PersonField1 PersonField2

供应商

SupplierID SuppFiel1 SuppField2

Department、Person和Supplier都有单独的表，因为它们的属性差别很大。但它们中的每一个都可以充当请求的请求者(RequesterID)。在没有充满不同可能的请求者的情况下，实现这一点的最好方法是什么？

希望这能有所帮助。。。

Answer 1

您需要在ER建模中称为继承(也称为。类别、子类型、泛化层次结构等)，如下所示：

​

​

通过这种方式，很容易为每个请求者类型提供不同的字段和FK，同时仍然只有一个请求表。从本质上讲，您可以在不强制更改请求的情况下更改请求者。

物理数据库中一般都有3 ways to represent inheritance。您尝试的基本上是策略#1 (合并单个表中的所有类)，但我建议使用策略#3 (每个类都在单独的表中)。

Answer 2

您可以有两个不同的ID: RequesterID和RequesterTypeID。对于Person、Department和Supplier，RequesterTypeID将分别为1、2或3，RequesterTypeID和RequesterID将共同构成一个多属性主键。

Answer 3

Jack Radcliffe的建议可能是最好的选择。所以我只需要添加一个替代选项：

你也可以考虑有3个请求表...一个用于ppl请求，一个用于供应商请求，还有一个用于部门请求...因此，您不需要显式地存储RequesterTypeID，因为您可以从表名中推断出它……然后，您可以创建表Jack Radcliffe作为一个视图，通过“联合”所有3个单独的表…

另外，如果你实现了Jack Radcliffe方法，你可以创建3个视图来模拟我提到的3个表……因此，您可以使用任何最适合每种情况的表/视图，如果您想从方法A更改为B，这也非常容易……