We’re designing a database that has a simple table called Person. Each person can have several roles related to him such as customer, staff member, manager and so forth. Each role will come with a list of properties and thus we have a table for each role as well.
Now we need to connect a person to his set of roles. What is the best way of doing this?
So far we’ve come up with two designs and we’re not sure which one is optimal in terms of scaling with further roles that might be introduced as well as keeping data integretity inside the database.
Our first design would have a single table that maps a person with a specific role, and an id in that role’s table. An entry in this table would look like
personid: 5
role: 2 (manager)
roleid: 6 (the id to look for in the manager table)
While this solution would scale with further roles added later in the process it has the disadvantage of not naturally enforcing data integrity through the use of foreign keys.
The other design would have a mapping table for each role. So there would be a StaffMemberMapping table with an entry resembling
personId: 5
staffMemberId: 12
This solution enforces data integrity through FKs but also requires us to look in several tables each time we lookup a person to see which roles he is related to.
Which one of these solution are favourable? Or even better, if there is a third more awesome solution please come with suggestions.
The second solution seems to be the natural choice, because, well, roles are relations between pairs of objects, and you model separate relations in relational databases with separate tables. I would suggest straying from normalized database designs only when there is a reason to do that, so I would go with (2), and only if there are performance issues, then denormalize the database and add (1) in addition to (2) for easier querying.