2

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

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

需要跟踪请求者是谁。

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

此外，Supplier 对象也需要与 Supplier 相关联。

所以这个想法是在 Request 表中有一个 RequestedByID FK。但是相关的请求者对每个数据都有如此不同的结构，如果它只是一个表（人们与部门和供应商有不同的属性），则需要一个完全非规范化的表才能关联回来。

我对如何处理这个问题有一些想法，但认为 SO 社区会有一些深刻的见解。

感谢您的任何帮助。

编辑：

伪结构：

要求

RequestID 请求者ID

部门

部门 ID DepField1 DepField2

人

人员 ID 人员字段 1 人员字段 2

供应商

供应商 ID SuppFiel1 SuppField2

Department、Person 和 Supplier 都有单独的表，因为它们的属性有很大不同。但是它们中的每一个都可以作为请求的请求者（RequesterID）。如果没有一个（非规范化表）充满不同的可能请求者，最好的方法是什么？

希望这可以帮助。. .

4

4 回答 4

2

You need what is in ER modeling know as inheritance (aka. category, subtype, generalization hierarchy etc.), something like this:

enter image description here

This way, it's easy to have different fields and FKs per requester kind, while still having only one REQUEST table. Essentially, you can varry the requester without being forced to also vary the request.

There are generally 3 ways to represent inheritance in the physical database. What you have tried is essentially the strategy #1 (merging all classes in single table), but I'd recommend strategy #3 (every class in separate table).

于 2012-07-19T08:22:39.037 回答
0

You could have two different IDs: RequesterID and RequesterTypeID. RequesterTypeID would just be 1, 2, or 3 for Person, Department, and Supplier, respectively, and RequesterTypeID paired with RequesterID would together make a multi-attribute primary key.

于 2012-07-19T01:51:14.717 回答
0

What Jack Radcliffe suggested is probably the best option. So I'd just add an alternative option:

You might also consider having 3 requests tables... One for ppl requests, one for suppliers requests, and one for departments requests... So you don't need to explicitly store the RequesterTypeID, since you can deduce it from the name of the table... You can then create the table Jack Radcliffe as a view, by "uniting" all the 3 individual tables...

Also, if you implement Jack Radcliffe approach, you can create 3 views to simulate the 3 tables I've mention... So then you can use whichever table/view is best for each situation, and if you want to change from approach A to B it's really easy too...

于 2012-07-19T01:56:05.903 回答
0

What I like about Jack Radcliffe's thought is if you store them in a separate table or make the sql statement generic to handle any number passed in by the application, they can be expanded e.g. manufacture, entity, subsidiary, etc

However, you choose the expansion will entail overhead.

于 2012-07-19T02:14:28.603 回答