Hi. You definitely don't want to create another table for a different type of manager, so you are doing it correctly. The only other "better" approach is maybe simply use the Employees table to get the ID for the managers, if they are also in the employees table. In other words, if the managers are also employees, then why create a separate table of managers?
Multiple foreign keys in table linked to same primary key in another table?
I have a database with a table named Managers. It stores a record for each manager in the organization. Some of those managers are Product Managers and some are Division Managers.
I have a Product Groups table that stores information about Products, including each product's Product Manager and Division Manager. I do not want to create separate tables for Product and Division managers since all manager fields are the same.
So I create relationships between the Product Groups table and two instances of the Managers table, as shown here.
Is this a viable approach for my table/relationship structure, or should I create separate physical tables for each type of manager? Is there a better way to set this up?
Microsoft 365 and Office | Access | For home | Windows
Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.
2 additional answers
Sort by: Most helpful
-
Anonymous
2019-04-12T21:46:43+00:00 Thanks for the reply and for the confirmation that this is an acceptable way to design the table structure. I see your point about an employees table. Thanks.
-
DBG 11,531 Reputation points Volunteer Moderator2019-04-13T16:24:29+00:00 Hi. You're welcome. Good luck with your project.