2016-07-05 93 views
5

Ho una tabella come questa:Quando dovrei contrassegnare una colonna come chiave primaria?

// cookies 
+----+---------+-------------------+------------+ 
| id | user_id |  token  | expire | 
+----+---------+-------------------+------------+ 
| 1 | 32423 | dki3j4rf9u3e40... | 1467586386 | 
| 2 | 65734 | erhj5473fv34gv... | 1467586521 | 
| 3 | 21432 | 8u34ijf34t43gf... | 1467586640 | 
+----+---------+-------------------+------------+ 

A pochi giorni che ci penso. Suppongo di non aver bisogno della colonna id. Attualmente la colonna id è PK e inoltre ho un indice univoco nella colonna token per renderlo unico e veloce per la ricerca.

Ora voglio sapere, posso rimuovere la colonna id dal tavolo e creare la colonna token come PK? È normale?

Per essere onesto, non ho mai creato un tavolo senza id colonna (è sempre stato il PK) finora, sì che è strano per me scegliere token colonna come il PK.

+0

La tua struttura attuale va bene. –

+0

@GordonLinoff Nella mia struttura attuale 'id' è il PK. va bene? – stack

+7

Google "Chiave naturale contro chiave surrogata". Ci sono vantaggi/svantaggi per entrambi e quale è meglio per il tuo sistema dipenderà dalle tue esigenze specifiche. –

risposta

2

Nella misura in cui token è un varchar ampio, vorrei rimanere con il PK di IA int che si ha già. I join saranno più veloci. Così anche gli inserti. Gli aggiornamenti sarebbero probabilmente la stessa velocità, perché, perché sarebbe stata aggiornata la colonna forzando così le modifiche alla struttura dell'indice. Tuttavia, gli inserti sono più veloci per le relazioni secondarie non trascinando l'ampio varchar in un albero dell'indice.

Si tratta di preferenze e di leggibilità. Per quanto riguarda la leggibilità, c'è poco di questo con un tale varchar. Non è come se fosse una categoria come "scarpe". È una miserabile forma non umana illeggibile. Per quanto riguarda la leggibilità, non vi è alcun argomento per avere lo token come PK. Certo, a volte può essere leggermente utile.

addizionali compositi (indici a più colonne)

Quando si avvia combinando la PK di scelta con altre colonne compagni in materiali compositi (indici aggiuntivi si può scegliere di avere), la sottile int diventerà molto evidente per essere la scelta migliore Anche con dataset moderatamente grandi.

1

In generale, spesso preferiamo che l'id della tabella sia la chiave primaria, ma ciò che è primario è che non dovrebbe essere nullo e deve identificare in modo univoco i record di resto della tabella (colonne), quindi se si desidera effettuare il token come chiave primaria è facilmente eseguibile, ma assicurati che (Id) non dipenda dalle altre tabelle. quindi ogni volta che devi recuperare qualsiasi record puoi facilmente recuperarlo usando il token.