SQL: alla chiave primaria o no alla chiave primaria?

Question

Ho una tabella con set di impostazioni per gli utenti, ha le seguenti colonne:

UserID INT
Set VARCHAR(50)
Key VARCHAR(50)
Value NVARCHAR(MAX)
TimeStamp DATETIME

UserID insieme a Set e Key sono unici. Quindi un utente specifico non può avere due delle stesse chiavi in ??un particolare set di impostazioni. Le impostazioni vengono recuperate dal set, quindi se un utente richiede una determinata chiave da un determinato set, l'intero set viene scaricato, in modo che la prossima volta che è necessaria una chiave dallo stesso set, non deve andare nel database .

Dovrei creare una chiave primaria su tutte e tre le colonne (userid, set e key) o dovrei creare un campo aggiuntivo che ha una chiave primaria (ad esempio un numero intero di autoincremento chiamato SettingID, cattiva idea credo), oppure no creare una chiave primaria e creare un indice univoco?

----- AGGIORNAMENTO -----

Solo per chiarire le cose: questa è una fine della tabella delle linee, non è comunque unita. UserID è un FK per la tabella Users. Set non è un FK. È praticamente una tabella di supporto per la mia GUI. Ad esempio: gli utenti ottengono la prima volta che visitano parti del sito Web, un fumetto di aiuto, che possono chiudere se lo desiderano. Una volta fatto clic, aggiungerò alcune impostazioni a " Getting Started " set che indicherà che helpballoon X è stato disabilitato. La prossima volta che l'utente arriva alla stessa pagina, l'impostazione indicherà che il fumetto X non dovrebbe più essere mostrato.

Answer 1

  

Devo creare una chiave primaria su tutte e tre le colonne (userid, set e key)

Crea questo.

L'uso della chiave primaria surrogata si tradurrà in una colonna aggiuntiva che non viene utilizzata per altri scopi.

La creazione di un UNICO INDICE insieme alla chiave primaria surrogata è la stessa della creazione di un PRIMARY KEY non cluster e si tradurrà in un ulteriore KEY lookup che è peggio per le prestazioni.

La creazione di un UNICO INDICE senza un PRIMARY KEY comporterà una tabella organizzata da HEAP che richiederà una ricerca RID aggiuntiva per accedere ai valori: anche non molto buono.

Answer 2

Avere chiavi univoche composte non è una buona idea.

Avere qualsiasi dato rilevante per l'azienda come chiave primaria può anche creare problemi. Ad esempio, se è necessario modificare il valore. Se nell'applicazione non è possibile modificare il valore, potrebbe essere in futuro o deve essere modificato in uno script di aggiornamento.

È meglio creare una chiave surrogata, un numero automatico che non abbia alcun significato commerciale.

Modifica dopo l'aggiornamento:

In questo caso, puoi pensare di non avere concettualmente nessuna chiave primaria e rendere queste tre colonne la chiave primaria di una chiave unica composita (per renderla modificabile).

Answer 3

Quante chiavi e set hai? Devono essere varchar (50) o possono indicare una tabella di ricerca? Se puoi convertire questo Set e Key in SetId e KeyId, puoi creare la tua chiave primaria sui 3 valori interi che saranno molto più veloci.

Answer 4

Probabilmente proverei ad assicurarmi che UserID fosse un identificatore univoco, piuttosto che avere duplicati di UserID in tutto il codice. I tasti compositi tendono a confondersi più tardi nella vita del tuo codice.

Suppongo che questo sia un campo di ricerca per i valori di configurazione di qualche tipo, quindi potresti probabilmente usare la chiave composita in questo caso. I dati sono già lì. Puoi garantire la sua unicità usando la chiave primaria. Se cambi idea e decidi in seguito che non è appropriato per te, puoi facilmente aggiungere un SettingId e rendere la chiave composita originale un indice univoco.

Answer 5

Creane una chiave primaria separata. Indipendentemente da come cambierà la logica di bussines, quali nuove regole dovranno essere applicate al campo Key VARCHAR (50) - avere una chiave primaria ti renderà completamente indipendente dalla logica di bussines.

Answer 6

Nella mia esperienza tutto dipende da quante tabelle useranno questa tabella come informazione FK. Vuoi 3 colonne extra nelle tue altre tabelle solo per trasportare un FK?

Personalmente vorrei creare un'altra colonna FK e mettere un vincolo univoco sulle altre tre colonne. Questo rende le chiavi esterne di questo tavolo molto più facili da ingoiare.

Answer 7

Non sono un sostenitore delle chiavi composite, ma in questo caso come fine della tabella delle linee, potrebbe avere senso. Tuttavia, se si accettano valori null in uno di questi tre campi poiché uno o più valori non sono noti al momento dell'inserimento, potrebbero esserci difficoltà e un indice univoco potrebbe essere migliore.

Answer 8

Meglio avere UserID come newid () a 32 bit o identificatore univoco perché UserID come int fornisce un suggerimento all'utente del probabile UserID. Ciò risolverà anche il problema della chiave composita.