Ho le seguenti tabelle nel server MySQL:Come far valere unici in più tabelle
Companies:
- UID (unique)
- NAME
- other relevant data
Offices:
- UID (unique)
- CompanyID
- ExternalID
- other data
Employees:
- UID (unique)
- OfficeID
- ExternalID
- other data
In ognuno di essi l'UID è identificatore unico, creato dal database.
Esistono chiavi esterne per garantire i collegamenti tra Dipendente -> Ufficio -> Società sull'UID.
I campi ExternalID in Uffici e Dipendenti sono l'ID fornito alla mia applicazione dalla Società (i miei clienti in realtà). I clienti non hanno (e non si preoccupano) dei miei ID personali e tutti i dati ricevuti dalla mia applicazione vengono identificati esclusivamente in base ai loro ID (ad esempio ExternalID nelle mie tabelle).
I.e. una richiesta dal client in pseudo-lingua è come "I'm Company X, aggiornare i dati per il mio dipendente Y".
Ho bisogno di forzare l'unicità sulla combinazione di CompanyID e Employees.ExternalID, quindi nel mio database non ci sarà nessun ExternalID duplicato per i dipendenti della stessa azienda.
Stavo pensando a 3 possibili soluzioni:
modificare lo schema per i dipendenti per includere CompanyID e creare vincolo unico su due campi.
Applicare un trigger, che in fase di aggiornamento/inserimento in Dipendenti conferma l'unicità.
Applica il controllo a livello di applicazione (ad esempio il mio servizio di ricezione).
My alternative-dbadmin-in-me sais che (3) è la soluzione peggiore, in quanto non protegge il database di incoerenza in caso di errore dell'applicazione o qualcosa d'altro, e molto probabilmente sarà il più lento uno.
La soluzione di attivazione può essere quello che voglio, ma può diventare complicato, soprattutto se è necessario eseguire più inserimenti/aggiornamenti in una singola istruzione e non sono sicuro della prestazione rispetto a (1).
E (1) sembra l'approccio più rapido e semplice, ma in qualche modo va contro la mia comprensione del modello relazionale.
Quali opinioni degli esperti di SO DB riguardano i pro e i contro di ciascuno degli approcci, specialmente se esiste la possibilità di aggiungere un ulteriore livello di riferimento indiretto - ovvero Azienda -> Ufficio -> Dipartimento -> Dipendente e la stessa unicità deve essere preservato (Azienda/Dipendente).
@OMG: Sì, le chiavi esterne sono chiavi esterne. Non li ho aggiunti nella Q per semplicità. Grazie comunque per averlo scoperto. Modificherò la Q. –