È necessaria una colonna ID univoca in una tabella molti-a-molti (giunzione)?

Credo che tu intenda la tabella "junction", non la tabella "join".

Non è necessario che una tabella di giunzione abbia il proprio campo ID. Non avresti mai bisogno di unirti o filtrare su un tale ID. Dovresti unire o filtrare solo gli ID delle tabelle che stai mappando. Un ID su una tabella di congiunzione è uno spreco di spazio su disco.

Quindi l'opzione "migliore" è evitare l'ID. In genere una tabella di giunzione avrà 2 indici di copertura. Ciascun indice di copertura che utilizza uno degli ID associati come campo di ordinamento principale.

Ma il "meglio" non è da molto tempo. È un problema molto secondario avere un campo ID ridondante. Non avrai storie horror su una piccola quantità di disco sprecato. L'ID non "ruba" l'indice cluster perché non vuoi comunque cluster sulla combo mappata.

Se il tuo framework vuole che tutte le tabelle abbiano un ID, allora cerca di farlo. Se gli standard del database del tuo team dettano che tutte le tabelle devono avere un ID, allora vai a prenderlo. In caso contrario, evitalo.

Nel corso degli anni ho preso l'abitudine di dare a ogni tabella "TableName" una chiave primaria generata automaticamente "TableNameID", senza eccezioni, nemmeno per le tabelle di junction. Posso dire che non me ne sono mai pentito, perché rende molte cose più semplici quando si crea codice generico che fa qualcosa per "tutte le tabelle" o "alcune tabelle" o per "molte righe di più tabelle diverse".

Ad esempio, se qualcuno ti chiede di memorizzare alcune righe di tabelle diverse (o riferimenti a quelle) in un file o in memoria, ad esempio, per scopi di registrazione, è molto utile quando sai in anticipo che devi solo memorizzare esattamente un nome di tabella & esattamente un ID intero e non devi occuparti di "casi speciali".

Un'altra cosa, quando inizi con PK combinati, probabilmente dovrai ricorrere alcune volte in seguito alla necessità di combinazioni di chiavi esterne (dato che potresti arrivare ad un punto in cui vuoi aggiungere un riferimento FK alla tua tabella ApplicationPermissions ) . Quindi il prossimo requisito potrebbe essere quello di rendere questo FK univoco in combinazione con altri attributi o chiavi esterne - il che comporterà una maggiore complessità complessiva. Nulla che non sia possibile gestire per la maggior parte dei sistemi DB moderni, ma una soluzione uniforme rende la vita dei programmatori spesso molto più semplice.

E infine, un'istruzione come SELECT ... FROM TABLE WHERE TableNameID IN (id1,id2,...) funziona bene con una singola colonna come chiave primaria, ma non ho mai visto finora un dialetto SQL che ti permetta di farlo con le chiavi combinate. Se sai in anticipo che non avrai mai bisogno di una query come questa, bene, ma non stupirti se domani riceverai un requisito che sarà risolto più facilmente con questo tipo di SQL.

Naturalmente, quando ti aspetti che la tua tabella ApplicationPermissions contenga centinaia di milioni di righe, dovresti prendere in considerazione di evitare qualcosa come ApplicationPermissionsID .

Mentre la risposta di Mike è buona, ecco i motivi per cui aggiungerei un campo ID separato o no.

1. Considera di utilizzare un campo ID separato per la tabella junction / join se contiene campi diversi dall'ID . Questo tende a notare che è un'entità di prima classe.

2. Considera l'utilizzo di un campo ID separato se le API o qualsiasi logica esistente tendono a utilizzare singoli campi per recuperare / modificare entità. Ciò può aiutare altre persone a seguire il tuo codice nel contesto di un progetto più ampio.

3. Non usarlo se non ci sono vantaggi specifici (KISS). EF sa come gestire questo tipo di tabella e talvolta può mancare un vincolo univoco composito quando altre persone cercano di capire questo tipo di relazione. Inoltre, durante la normalizzazione cerco di utilizzare la più piccola chiave possibile che definisca in modo univoco la tupla . Nel tuo secondo esempio, hai effettivamente 2 chiavi primarie candidate separate.

table Person
   Id int identity(1,1) not null primary key
   ...other fields go here...
table Address
   Id int identity(1,1) not null primary key
   ...other fields go here...
table PersonAddress
   Id int identity(1,1) not null primary key
   PersonId int not null
   AddressId int not null

Ricorda di creare un indice e una chiave esterna sia in PersonId che in AddressId .

Indipendentemente da ciò che gli altri pensano siano "migliori" o "dovresti", questo è il modo più semplice e semplice per consentire al database di funzionare correttamente.