Perché dovremmo avere una colonna ID nella tabella degli utenti?

Question

È ovvio che abbiamo già un'altra informazione univoca su ciascun utente, e questo è username. Quindi, perché abbiamo bisogno di un'altra cosa unica per ogni utente? Perché dovremmo avere anche un ID per ciascun utente? Cosa succederebbe se omettiamo la colonna id?

Answer 1

Anche se il nome utente è unico, ci sono alcuni vantaggi ad avere una colonna id in più invece di utilizzare il varchar come chiave primaria.

• Alcune persone preferiscono utilizzare una colonna integer come chiave primaria, per servire come una chiave surrogata che non ha bisogno di cambiare, anche se altre colonne sono soggette a modifiche. Sebbene non vi sia nulla che impedisca la possibilità che una chiave primaria naturale sia mutevole, è necessario utilizzare vincoli di chiave esterna a cascata per garantire che le chiavi esterne nelle tabelle correlate vengano aggiornate in sincrono con tali modifiche.

• 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 wedging nel centro dell'indice. Gli indici nelle tabelle MySQL sono solitamente strutture dati B + Tree e puoi studiarli per capire come si comportano.

• Alcuni framework di applicazioni preferiscono la convenzione che ogni tabella del database ha una colonna chiave primaria denominata id, anziché utilizzare chiavi naturali o chiavi composte. Seguendo tali convenzioni è possibile semplificare alcune attività di programmazione.

Nessuno di questi problemi è un affare. E ci sono anche vantaggi di utilizzare i tasti naturali:

• Se guardi in alto le righe per soprannome più spesso di quanto la ricerca per ID, può essere meglio scegliere il nome utente come chiave primaria, e sfruttare la archiviazione organizzata da indice di InnoDB. Rendi la tua colonna di ricerca principale la chiave primaria, se possibile, perché le ricerche di 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 per mantenere una colonna id in più di cui non hai bisogno.

• L'utilizzo di una chiave naturale indica che le chiavi esterne contengono un valore leggibile dall'uomo, anziché un numero intero arbitrario. Ciò consente alle query di utilizzare il valore della chiave esterna senza dover tornare alla tabella padre per il valore "reale".

Il punto è che non esiste una regola che copre il 100% dei casi. Consiglio spesso di mantenere aperte le opzioni e di utilizzare chiavi naturali, chiavi composte e chiavi surrogate anche in un singolo database.

Nel capitolo "ID richiesto" del mio manuale SQL Antipatterns: Avoiding the Pitfalls of Database Programming sono riportati alcuni problemi relativi alle chiavi surrogate.

Answer 2

Una ragione per avere un ID numerico è che la creazione di un indice su di essa è più magro che su un campo di testo, riducendo le dimensioni dell'indice e di elaborazione tempo necessario per cercare un utente specifico. Inoltre è meno byte da salvare quando si fa riferimento incrociato a un utente (database relazionale) in una tabella diversa.

Answer 3

A mio parere, ogni tavolo dovrebbe avere un unico, auto-incrementato id.

Ecco alcuni motivi pratici. Se hai righe duplicate, puoi facilmente determinare quale riga eliminare. Se vuoi sapere l'ordine in cui sono state inserite le righe, hai queste informazioni nell'ID. Per quanto riguarda gli utenti, c'è più che su "John Smith" nel mondo. Un ID fornisce una chiave per riferimenti stranieri.

Infine, qualsiasi cosa che possa descrivere un utente - un nome, un indirizzo, un numero di telefono, un indirizzo email - potrebbe cambiare nel corso del tempo.

Answer 4

im mysql abbiamo.

1:Index fields 2:Unique fields and 3:PK fields. 
index means pointable 
unique means in a table must be one in all rows. 
PK = index + unique 

in una tabella si può avere un sacco di campi unici come
nome utente o il passaporto codice o e-mail.
ma è necessario un campo come ID. che è sia univoco che index (= PK). il quale è il primo è sempre una cosa e non cambia mai e il secondo è unico e il terzo è semplice (perché spesso è il numero).

Answer 5

Questo identificatore è conosciuto come un Surrogate Key. La pagina I link elenca sia i vantaggi che gli svantaggi.

In pratica, ho trovato loro di essere vantaggiosa perché anche i dati Supertasti possono cambiare nel tempo (ad esempio l'indirizzo email di un utente può cambiare e quindi eventuali rapporti corrispondenti mosto cambiamento), ma una chiave surrogata non ha bisogno di cambiare per i dati che identifica perché il suo valore non ha senso per la relazione.

È anche bello da un punto di vista JOIN perché può essere un numero intero con una lunghezza della chiave minore rispetto a un varchar.

Posso dire che in pratica preferisco usarli. Sono stato morso troppe volte perché le chiavi primarie a più colonne o una superkey rappresentativa dei dati utilizzata su tabelle dovevano diventare non univoci in seguito a causa dei mutevoli requisiti durante lo sviluppo e non è una situazione che si desidera gestire.