È utile utilizzare chiavi primarie a più colonne (composte) per una tabella di relazioni molte a molte quando si utilizza Linq to SQL?È utile utilizzare chiavi primarie a più colonne (composite) quando si utilizza Linq to SQL?
Oppure devo semplicemente aggiungere una colonna Identity come chiave primaria non cluster e indicizzare le colonne FK in modo appropriato?
Non è un problema di LINQ. Se ne hai bisogno per il tuo schema, allora usali. Se non lo fai, non farlo. In ogni caso, LINQ gestirà il tuo schema bene.
Un'area che LINQ to SQL non gestisce bene è una tabella multy column/key mapping che viene utilizzata per connettere una relazione molti a molti, ma non direi che questo rientra in modo significativo nella categoria a cui si riferisce la domanda. È comunque possibile eseguire operazioni CRUD su una tabella di mappatura all'interno di LINQ ma LINQ non può eseguire la relazione presentata da una tabella di mappatura da molti a molti. (LINQ funziona bene con tabelle uno a uno e uno a molti.)
Non riesco a parlare con alcun problema con Entity Framework ma, ancora una volta, sarei molto sorpreso se l'EF avesse problemi con multi-column/tavoli multi-chiave.
Se nel proprio dominio è necessario disporre di una chiave composita a più colonne, quindi utilizzarne una. Altrimenti usa la solita colonna Identity come chiave primaria surrogata.
EDIT: era un consiglio generale e non tenendo conto degli aspetti tecnici dell'implementazione di LINQtoSQL. Questi possono essere di interesse:
Immagino che questo significhi che Linq to SQL possa gestire le chiavi composite senza guasti o sforzi aggiuntivi? –
In realtà, questo era esattamente un problema da molti a molti, grazie –