How to enforce uniques across multiple tables

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 f开发者_如何学JAVArom 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).

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

Each of your company-provided tables should include CompanyID into the `UNIQUE KEY' over the company-provided ids.

Company-provided referential integrity should use company-provided ids:

CREATE TABLE company (
        uid INT NOT NULL PRIMARY KEY,
        name TEXT
        );

CREATE TABLE office (
        uid INT NOT NULL PRIMARY KEY,
        companyID INT NOT NULL,
        externalID INT NOT NULL,
        UNIQIE KEY (companyID, externalID),
        FOREIGN KEY (companyID) REFERENCES company (uid)
        );

CREATE TABLE employee (
        uid INT NOT NULL PRIMARY KEY,
        companyID INT NOT NULL,
        officeID INT NOT NULL,
        externalID INT NOT NULL,
        UNIQIE KEY (companyID, externalID),
        FOREIGN KEY (companyID) REFERENCES company(uid)
        FOREIGN KEY (companyID, officeID) REFERENCES office (companyID, externalID)
        );

etc.

Set auto_increment_increment to the number of table you have. SET auto_increment_increment = 3; (you might want to set this in your my.cnf)

Then manually set the starting auto_increment value of each table to different values first table to 1, second table to 2, third table to 3

Table 1 will have values like 1,4,7,10,13,etc

Table 2 will have values like 2,5,8,11,14,etc

Table 3 will have values like 3,6,9,12,15,etc

Of course this is just ONE option, personally I'd just make it a combo value. Could be as simple as TableID, AutoincrementID, Where the TableID is constant in all rows.