I need to store information for staff. Each database instance is per parent company with multiple outlets underneath. Some of the staff that work at an outlet can potentially also work at other outlets, however as each outlet is for the most part autonomous, each outlet will not want other outlets to see their staff list.
I wanted to create unique staff instances and just relate them to the outlets that employ them, keeping their details uniform across the database. However my colleague wishes to allow each outlet to create their own staff members. The consequence of this approach is that John Smith might be a staff member at outlet A, Jonathan smith at outlet B and J smith at outlet C (as each outlet could enter pretty much whatever they want). Also each staff member has a set of skills and services associated with them, which also will not be uniform between outlets.
Will this approach cause problems down the line? At the outlet level it probably won’t make any difference, but I am concerned that if the parent group ask for reports, the results may be misleading as perhaps 5 staff members might be returned, which in reality are the same person, however may have different details.
What you are describing, if I understand you correctly, is choosing between the prospect of denormalizing a person record per outlet (giving each outlet a completely independent copy of John Smith) vs. defining a single John Smith and then defining related tables that could belong to the outlet level of access.
If you have a choice (the freedom to design the system either way) the normalized way with only 1 John Smith + auxiliary tables with outlet-specific details when necessary is the correct way. I hesitate to say ‘correct’, but in the absence of very large numbers of users I would say denormalization here would only lead to avoidable integrity errors.
If you choose to denormalize now and not relate John Smith at outlet A to John Smith at outlet B even though they are in reality the same person you are both opening the door to illogical data (updates to one John and not both) and losing the ability to do simple things like count the distinct number of people in the database.
Failing to identify unique people now will prevent you from being able to properly relate other entities to a person in the future. This will complicate your queries at the very least and give rise to logically incorrect but technically correct information in many cases.