Question

I have the following tables in MySQL server:

Companies:
- UID (unique)
- NAME
- other relevant data

Offices:
- UID (unique)
- CompanyID
- ExternalID
- other data

Employees:
- UID (unique)
- OfficeID
- ExternalID
- other data

In each one of them the UID is unique identifier, created by the database.

There are foreign keys to ensure the links between Employee -> Office -> Company on the UID.

The ExternalID fields in Offices and Employees is the ID provided to my application by the Company (my client(s) actually). The clients does not have (and do not care) about my own IDs, and all the data my application receives from them is identified solely based on their IDs (i.e. ExternalID in my tables).

I.e. a request from the client in pseudo-language is like “I’m Company X, update the data for my employee Y”.

I need to enforce uniqueness on the combination of CompanyID and Employees.ExternalID, so in my database there will be no duplicate ExternalID for the employees of the same company.

I was thinking about 3 possible solutions:

1. Change the schema for Employees to include CompanyID, and create unique constrain on the two fields.

2. Enforce a trigger, which upon update/insert in Employees validates the uniqueness.

3. Enforce the check on application level (i.e. my receiving service).

My alternative-dbadmin-in-me sais that (3) is the worst solution, as it does not protect the database of inconsistency in case of application bug or something else, and most probably will be the slowest one.

The trigger solution may be what I want, but it may become complicated, especially if a multiple inserts/updates need to be performed in a single statement, and I’m not sure about the performance vs. (1).

And (1) looks the fastest and easiest approach, but kind of goes against my understanding of relational model.

What SO DB experts opinion is about pros and cons of each of the approaches, especially if there is a possibility for adding an additional level of indirection – i.e. Company -> Office -> Department -> Employee, and the same uniqueness needs to be preserved (Company/Employee).

Answer 1

You’re right – #1 is the best option.
Granted, I would question it at first glance (because of shortcutting) but knowing the business rule to ensure an employee is only related to one company – it makes sense.

Additionally, I’d have a foreign key relating the companyid in the employee table to the companyid in the office table. Otherwise, you allow an employee to be related to a company without an office. Unless that is acceptable…

Triggers are a last resort if the relationship can not be demonstrated in the data model, and servicing the logic from the application means the logic is centralized – there’s no opportunity for bad data to occur, unless someone drops constraints (which means you have bigger problems).