Anche se il tuo nome utente è unico, ci sono pochi vantaggi nell'avere una colonna ID aggiuntiva invece di usare varchar come chiave primaria.
-
Alcune persone preferiscono utilizzare una colonna intera come chiave primaria, per fungere da chiave surrogata che non deve mai essere modificata, anche se altre colonne sono soggette a modifiche. Sebbene nulla impedisca che anche una chiave primaria naturale sia modificabile, dovresti utilizzare vincoli di chiave esterna a cascata per assicurarti che le chiavi esterne nelle tabelle correlate vengano aggiornate in sincronia con qualsiasi modifica di questo tipo.
-
La chiave primaria essendo un intero a 32 bit invece di un varchar può risparmiare spazio. La scelta tra una colonna di chiave esterna int o varchar in ogni altra tabella che fa riferimento alla tabella utente può essere una buona ragione.
-
L'inserimento nell'indice della chiave primaria è un po' più efficiente se si aggiungono nuove righe alla fine dell'indice, rispetto a quando si incastrano nel mezzo dell'indice. Gli indici nelle tabelle MySQL sono solitamente strutture di dati B+Tree e puoi studiarle per capire come si comportano.
-
Alcuni framework applicativi preferiscono la convenzione che ogni tabella nel database abbia una colonna chiave primaria chiamata
id, invece di usare chiavi naturali o chiavi composte. Seguire tali convenzioni può semplificare alcune attività di programmazione.
Nessuno di questi problemi è un problema. E ci sono anche vantaggi nell'usare le chiavi naturali:
-
Se cerchi le righe per nome utente più spesso di quanto cerchi per ID, può essere meglio scegliere il nome utente come chiave primaria e sfruttare l'archiviazione organizzata per indici di InnoDB. Rendi la tua colonna di ricerca primaria la chiave primaria, se possibile, perché le ricerche delle chiavi primarie sono più efficienti in InnoDB (dovresti usare InnoDB in MySQL).
-
Come hai notato, se hai già un vincolo univoco sul nome utente, sembra uno spreco di spazio di archiviazione mantenere una colonna ID aggiuntiva che non ti serve.
-
L'uso di una chiave naturale significa che le chiavi esterne contengono un valore leggibile dall'uomo, invece di un ID intero arbitrario. Ciò consente alle query di utilizzare il valore della chiave esterna senza dover ricongiungersi alla tabella padre per il valore "reale".
Il punto è che non esiste una regola che copra il 100% dei casi. Consiglio spesso di mantenere aperte le opzioni e di utilizzare chiavi naturali, chiavi composte e chiavi surrogate anche in un unico database.
Tratto alcuni problemi delle chiavi surrogate nel capitolo "ID richiesto" nel mio libro SQL Antipatterns:Evitare le insidie della programmazione di database .
