Home/ Questions/Q 8288067
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-08T12:12:14+00:00

I have a database structure issue I am looking for some opinions on. Let’s

  • 0

I have a database structure issue I am looking for some opinions on.

Let’s say there is a scenario where users will use an application to request materials.

There is the need to track who the requester is.

There are three possible “types” of requesters. An individual (Person), a Department, and the Supplier supplying the materials themselves.

In addition the Supplier object needs to be related as the Supplier as well.

So the idea is in the Request table there is a RequestedByID FK. But the related requester has such a different structure for the data for each that it would require a completely denormalized table to related back to if it were made just a single table (people have different properties than departments, and suppliers).

I have some ideas on how I might handle this but thought the SO community would have some great insight.

Thanks for any and all help.

EDIT:

pseudo structure:

Request

RequestID
RequesterID

Department

DepartmentID
DepField1
DepField2

Person

PersonID
PersonField1
PersonField2

Supplier

SupplierID
SuppFiel1
SuppField2

Department, Person, and Supplier all have separate tables because they differ in their properties quite a bit. But each of them can serve as the Requester of a Request (RequesterID). What is the best way to accomplish this without one (denormalized table) full of the different possible requesters?

Hope this helps. . .

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    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).

    • 0