Dovrei usare una chiave composta per una tabella carta, che viene utilizzato anche per una chiave esterna?

Question

Sto usando ASP.NET e Entity Framework per fare un sito web. Al momento ho una tabella di mappa per una relazione molti a molti tra ... diciamo che gli utenti e le squadre di calcio. Quindi:

Gli utenti
squadre
UserTeams

Parte 1 : E 'buona norma usare una chiave composta per la chiave primaria della tabella mappa? In altre parole:

UserTeams Tavolo
PK UserId
PK teamid
PreferenceId

Parte 2 : L'avvertenza è che ho anche un altro tavolo. Chiamiamolo "UserTeamPredictions" che memorizza le previsioni degli utenti per un determinato gruppo per ogni anno. Questo tavolo ha una chiave esterna che punta di nuovo al tavolo della mappa. Quindi sembra qualcosa di simile:

UserTeamPredictions Tavolo
PK UserTeamPredictionId
FK UserId
FK teamid
Predizione PredictionYear

Questo sembra funzionare bene in Entity Framework, però, ho avuto qualche problema quando si fa riferimento a rapporti di controlli di terze parti che uso come Telerik. Anche se potrebbe non essere la messa a punto di dati ideale, dovrei cambiare la struttura della tabella / relazioni in modo che la sua più facile lavorare con il codice di associazione dati e altre cose?

Il cambiamento sarebbe di aggiungere una chiave primaria intero alla mappa tavolo UserTeams, permettendo la tabella UserTeamPredictions fare riferimento direttamente la chiave, anziché tramite la chiave composta come avviene attualmente:

UserTeams Tavolo
PK UserTeamId
FK UserId
FK teamid
PreferenceId

UserTeamPredictions Tavolo
PK UserTeamPredictionId
FK UserTeamId
Predizione PredictionYear

Cosa ne pensi!?

Answer 1

avrei scelto di non farlo. Vorrei usare una chiave surrogata e mettere un indice univoco sulle colonne UserID e teamid. Mi sento davvero stufo di chiavi composte quando ci sono più di due, e piuttosto che avere un mix di chiavi composte e surrogate, mi scegliere di andare con tutta la surrogata, senza senso chiavi autoincremento ove possibile.

Questo ha il vantaggio di dare buone prestazioni sul join e significa che si conosce sempre la chiave per una determinata tabella (nome tabella + ID), senza la necessità di fare riferimento allo schema. Alcuni strumenti ORM funzionano correttamente solo con un'unica colonna, piuttosto che le chiavi composte, anche.

Answer 2

Si dovrebbe cambiarlo. Cerca Stack Overflow per le discussioni sul "chiavi naturali" - è quasi universalmente accettato che chiavi surrogate sono migliori, soprattutto quando si utilizza la generazione entità. chiavi fisiche o compositi fanno non giocare bene con i livelli DAL entità stile quadro in generale. Ad esempio, Lightspeed e Subsonic entrambi richiedono la presenza di una singola colonna unica come PK ... Lightspeed in essa la versione attuale si spinge fino ad insistere che la colonna si chiama "Id", anche se cambieranno prossima versione.