C'è qualche vantaggio di una chiave primaria che comprende tutte le colonne della tabella?

Ho una tabella con quattro colonne tutte non annullabili e i dati sono tali che tutte e quattro sono necessarie per distinguere un record univoco. Ciò significa che se dovessi creare una chiave primaria, dovrebbe comprendere tutte le colonne. Le query sulla tabella saranno quasi sempre per il ripristino di un singolo record, ovvero tutte le colonne verranno filtrate nella query.

Poiché ogni colonna dovrà essere cercata, avere una chiave primaria mi avvantaggia (oltre a far rispettare l'unicità dei record)?

Nel tuo caso questi campi sono la chiave naturale .

Chiave surrogata:

Le chiavi surrogate sono chiavi che non hanno un significato "commerciale" e sono utilizzate esclusivamente per identificare un record nella tabella. Tali chiavi sono generate dal database (esempio: identità in SQL Server, sequenza in Oracle, sequenza / identità in DB2 UDB ecc.) O valori generati dal sistema (come generati tramite una tabella nello schema).

Chiave naturale:

Le chiavi sono naturali se l'attributo che rappresenta viene utilizzato per l'identificazione indipendentemente dallo schema del database. Ciò significa sostanzialmente che le chiavi sono naturali se le persone le usano come esempio: numeri di fattura, ID imposta, SSN ecc.

Chiavi surrogate vs Chiavi naturali per chiave primaria

Preferisco aggiungere una chiave surrogata per separare la gestione dei modelli di business e database. Un'altra domanda è l'utilizzo dell'indice cluster e non cluster sulla chiave primaria. Se si modificano le tabelle (tabella non statica, ha inserimenti o aggiornamenti ad alta intensità), si verificheranno problemi con le prestazioni nel caso in cui si utilizzi l'indice cluster su chiave aumentata non monotonica.

In genere, si consiglia di disporre di una chiave surrogata in tali situazioni, quindi chiavi esterne in altre tabelle (e qualsiasi riferimento di record che può essere archiviato esternamente, ad esempio se vengono portate su stringhe di query in cui una richiesta http (s) fa riferimento a una dei record) hanno qualcosa a cui fare riferimento che non cambierà se i dati nella riga cambiano. Se lo fai, questa sarebbe la tua chiave primaria.

Se non aggiungi una chiave surrogata del genere, allora dato come descrivi i dati in accesso con tutte e quattro le colonne come chiave primaria non sarebbe uno svantaggio. Se si imposta la chiave come indice cluster per la tabella, le richieste saranno utili in quanto vi sarà un livello nell'albero b su disco per scendere per trovare i dati per una determinata riga.

Le chiavi composte come chiavi primarie si imbattono anche in problemi di dimensioni dell'indice che possono influire sull'utilizzo del disco, sulla velocità e sui backup. Puoi consultare i post di Kimberly Tripp sulle chiavi primarie e sugli indici cluster qui: http://www.sqlskills.com/BLOGS/KIMBERLY/post/The-Clustered-Index-Debate-again!.aspx

Anch'io suggerirei una chiave surrogata in questo caso anziché una chiave naturale.

Se hai una tabella che rappresenta una relazione molti-a-molti che ha solo 2 colonne, sembra ragionevole.

Cf. questa domanda così

Ma ammetto che aggiungo Surrogate Keys anche in quei casi.