Perché non dovrei avere una tabella per più relazioni?

Supponendo di avere più relazioni nel mio database, ad esempio Negozio, Dipendente e Vendita, e voglio connettere coppie con una semplice relazione binaria. Personalmente vorrei creare tabelle denominate Employee_Store e Employee_Sale con una chiave naturale composta da chiavi esterne.

Ora, il mio collega insiste sulla creazione di una tabella per più relazioni. Per l'esempio sopra potrebbe esserci una tabella chiamata EmployeeLinks:

EmployeeLinks(
    IdLink int PK, 
    IdEmployee int FK null,
    IdStore int FK null,
    IdSale int FK null,
    LinkType int not null
)

Ti prego, aiutami con buoni motivi per cui questa non è una buona idea. Ho dei miei argomenti, ma vorrei tenerli privati ​​e ascoltare le tue opinioni imparziali.

MODIFICARE:

Inizialmente la tabella sopra non avrebbe una chiave primaria (!). Poiché le chiavi esterne consentono null una chiave surrogata è l'unica opzione.

Cosa propone il tuo collega come chiave primaria per questa tabella di collegamenti?
Le colonne della chiave primaria non possono ovviamente essere NULL: la tabella sopra ha nullable.

Non esiste un identificatore di riga naturale (che è quello che è un PK) nell'esempio sopra (una colonna IDENTITY non è una chiave primaria), pertanto non riesce in alcun processo di modellazione. Non pensare nemmeno alla creazione di tabelle senza alcuni modelli (ERD, ORM, IDEF1X, qualunque cosa)

Avresti anche bisogno dei vincoli CHECK per assicurarti di non avere collegamenti a 3 vie.

Infine, ti stai allontanando nel 4 ° e 5 ° territorio in forma normale ma per ragioni sbagliate.

Non riesco a trovare alcun esempio su Internet: questo dimostra quanto sia stupido

La prima ragione pratica a cui riesco a pensare è la prestazione.

In un modello "tradizionale", puoi avere un indice univoco su Idemployee, Idstoreo qualunque sia il campo e ottenere grandi prestazioni nelle ricerche. È anche facile da mantenere per gli inserti. Gli indici univoci ti consentono di unire i join più frequentemente, il che può rendere molte JOINs incredibilmente veloci.

Nel tuo modello di esempio, per ottenere prestazioni decenti dovrai avere almeno un indice di campo singolo su ogni campo FK nella tabella, idealmente un indice di copertura su tutte le combinazioni a cui verrà fatto riferimento, ovvero:

• Impiegato / deposito
• Impiegato / Vendita

Non sono sicuro di quale sia il tipo di link, ma se lo fai riferimento, probabilmente dovrebbe essere indicizzato.

Questi indici dovranno essere mantenuti per ogni riga della tabella, indipendentemente dal fatto che il campo sia popolato o meno. Puoi aggiungere un filtro ma anche questo diventerà complicato con così tante combinazioni.

Complicherà anche la tua logica. Dovrai effettuare una ricerca sull'ididipendente, trovare una riga con un valore di archivio vuoto e aggiornare; o, basta inserire una nuova riga per ogni nuovo collegamento, che tipo di sconfigge lo scopo di consolidare i campi.

Fondamentalmente utilizzerai PIÙ spazio su disco, avrai PIÙ indici da mantenere e complicherai la tua logica praticamente per nessun motivo. L'unico "vantaggio" è che ci sono meno tavoli da gestire.

Inserire più relazioni in una tabella può essere utile se tali relazioni hanno gli stessi attributi e / o se si desidera aggregare i dati su più relazioni.

È necessario se i tipi di relazioni sono definiti dall'utente in fase di esecuzione. Tuttavia questo raramente è davvero il caso.

Nel tuo esempio le relazioni non condividono gli attributi, le relazioni fanno persino riferimento a due diverse tabelle. Ciò rende difficile applicare i vincoli e il design è anche meno intuitivo.

Sceglierei quel design solo se la creazione di tabelle costa letteralmente denaro.