Utilizzare l'indirizzo e-mail come chiave primaria?

L'indirizzo e-mail è un cattivo candidato per il primario rispetto ai numeri con incremento automatico?

La nostra applicazione web richiede che l'indirizzo e-mail sia univoco nel sistema. Quindi, ho pensato di usare l'indirizzo e-mail come chiave primaria. Tuttavia il mio collega suggerisce che il confronto delle stringhe sarà più lento del confronto dei numeri interi.

È un motivo valido per non utilizzare l'e-mail come chiave primaria?

Stiamo usando PostgreSQL.

Il confronto delle stringhe è più lento del confronto int. Tuttavia, questo non importa se si recupera semplicemente un utente dal database utilizzando l'indirizzo e-mail. È importante se hai query complesse con più join.

Se si memorizzano informazioni sugli utenti in più tabelle, le chiavi esterne della tabella degli utenti saranno l'indirizzo e-mail. Ciò significa che memorizzi più volte l'indirizzo e-mail.

Sottolineerò anche che l'e-mail è una cattiva scelta per creare un campo unico, ci sono persone e persino piccole imprese che condividono un indirizzo e-mail. E come i numeri di telefono, le e-mail possono essere riutilizzate. Jsmith@somecompany.com può facilmente appartenere a John Smith un anno e Julia Smith due anni dopo.

Un altro problema con le e-mail è che cambiano frequentemente. Se ti unisci ad altre tabelle con questo come chiave, allora dovrai aggiornare anche le altre tabelle, il che può essere un notevole successo in termini di prestazioni quando un'intera azienda client modifica le loro e-mail (cosa che ho visto accadere).

la chiave primaria dovrebbe essere unica e costante

gli indirizzi email cambiano come le stagioni. Utile come chiave secondaria per la ricerca, ma una scelta sbagliata per la chiave primaria.

Svantaggi dell'utilizzo di un indirizzo e-mail come chiave primaria:

1. Più lento quando si eseguono join.

2. Qualsiasi altro record con una chiave esterna registrata ora ha un valore maggiore, occupando più spazio su disco. (Dato il costo dello spazio su disco oggi, questo è probabilmente un problema banale, tranne nella misura in cui il record ora impiega più tempo a leggere. Vedi # 1.)

3. Un indirizzo e-mail potrebbe cambiare, costringendo tutti i record a utilizzarlo come chiave esterna per essere aggiornati. Poiché l'indirizzo e-mail non cambia molto spesso, il problema delle prestazioni è probabilmente minore. Il problema più grande è che devi assicurarti di provvedere. Se devi scrivere il codice, questo è più lavoro e introduce la possibilità di bug. Se il tuo motore di database supporta "on update cascade", è un problema minore.

Vantaggi dell'utilizzo dell'indirizzo e-mail come chiave primaria:

1. Potresti essere in grado di eliminare completamente alcuni join. Se tutto ciò di cui hai bisogno dal "record master" è l'indirizzo e-mail, allora con una chiave intera astratta dovresti fare un join per recuperarlo. Se la chiave è l'indirizzo e-mail, allora l'hai già e il join non è necessario. Se questo ti aiuta dipende dalla frequenza con cui si presenta questa situazione.

2. Quando si eseguono query ad hoc, è facile per un essere umano vedere a quale master record viene fatto riferimento. Questo può essere di grande aiuto quando si cerca di rintracciare i problemi dei dati.

3. Quasi sicuramente avrai bisogno di un indice sull'indirizzo e-mail, quindi renderlo la chiave primaria elimina un indice, migliorando così le prestazioni degli inserti in quanto ora hanno solo un indice da aggiornare invece di due.

Secondo la mia modesta opinione, in ogni caso non è una schiacciata. Tendo a preferire l'uso di chiavi naturali quando è disponibile una pratica perché sono semplicemente più facili da lavorare e gli svantaggi tendono a non avere molta importanza nella maggior parte dei casi.

È piuttosto male. Supponiamo che alcuni provider di posta elettronica non funzionino. Gli utenti vorranno quindi cambiare la loro e-mail. Se hai usato l'e-mail come chiave primaria, tutte le chiavi esterne per gli utenti duplicheranno quell'e-mail, rendendo molto difficile cambiare ...

... e non ho nemmeno iniziato a parlare di considerazioni sulle prestazioni.

Non so se questo potrebbe essere un problema nella tua configurazione, ma a seconda del tuo RDBMS i valori di una colonna potrebbero essere case sensitive . I documenti PostgreSQL dicono: "Se dichiari una colonna come UNIQUE o PRIMARY KEY, l'indice generato implicitamente fa distinzione tra maiuscole e minuscole". In altre parole, se si accetta l'input dell'utente per una ricerca in una tabella con e-mail come chiave primaria e l'utente fornisce "John@Doe.com", non si troverà "john@doe.com".

Nessuno sembra aver menzionato un possibile problema per cui gli indirizzi e-mail potrebbero essere considerati privati. Se l'indirizzo e-mail è la chiave primaria, molto probabilmente un URL della pagina del profilo avrà un aspetto simile ..../Users/my@email.com. Cosa succede se non si desidera esporre l'indirizzo e-mail dell'utente? Dovresti trovare un altro modo per identificare l'utente, possibilmente con un valore intero univoco per rendere simili gli URL ..../Users/1. Quindi alla fine si otterrebbe un valore intero univoco.

A livello logico , l'e-mail è la chiave naturale. A livello fisico , dato che si sta utilizzando un database relazionale, la chiave naturale non si adatta bene come chiave primaria. Il motivo è principalmente i problemi di prestazioni menzionati da altri.

Per tale motivo, il design può essere adattato. La chiave naturale diventa la chiave alternativa (UNIQUE, NOT NULL) e si utilizza una chiave surrogata / artificiale / tecnica come chiave primaria, che può essere un auto-incremento nel proprio caso.

systempuntoout ha chiesto,

Cosa succede se qualcuno vuole cambiare il suo indirizzo email? Cambierete anche tutte le chiavi esterne?

Ecco a cosa serve la cascata .

Un altro motivo per utilizzare una chiave surrogata numerica come chiave primaria è legato al funzionamento dell'indicizzazione nella piattaforma. In InnoDB di MySQL, ad esempio, tutti gli indici in una tabella hanno la chiave primaria pre-attesa, quindi vuoi che il PK sia il più piccolo possibile (per motivi di velocità e dimensioni). Anche in relazione a questo, InnoDB è più veloce quando la chiave primaria è memorizzata in sequenza, e una stringa non ci sarebbe di aiuto.

Un'altra cosa da prendere in considerazione quando si utilizza una stringa come chiave alternativa, è che l'uso di un hash della stringa effettiva desiderata potrebbe essere più veloce, saltando cose come maiuscole e minuscole di alcune lettere. (Sono effettivamente atterrato qui mentre cercavo un riferimento per confermare quello che ho appena detto; ancora alla ricerca ...)

Sì, è una chiave primaria errata perché gli utenti vorranno aggiornare i loro indirizzi e-mail.

sì, è meglio se usi invece un numero intero. puoi anche impostare la colonna e-mail come vincolo univoco.

come questo:

CREATE TABLE myTable(
    id integer primary key,
    email text UNIQUE
);

Un altro motivo per cui la chiave primaria intera è migliore è quando si fa riferimento all'indirizzo e-mail in una tabella diversa. Se l'indirizzo stesso è una chiave primaria, in un'altra tabella devi usarlo come chiave. Quindi memorizzi gli indirizzi e-mail più volte.

Non ho troppa familiarità con Postgres. Le chiavi primarie sono un argomento importante. Ho visto alcune domande e risposte eccellenti su questo sito (stackoverflow.com).

Penso che potresti avere prestazioni migliori avendo una chiave primaria numerica e utilizzando un INDICE UNICO nella colonna e-mail. Le e-mail tendono a variare in lunghezza e potrebbero non essere appropriate per l'indice della chiave primaria.

qualche lettura qui e qui.

Personalmente, non utilizzo alcuna informazione per la chiave primaria durante la progettazione del database, perché è molto probabile che possa essere necessario modificare qualsiasi informazione in un secondo momento. L'unica ragione per cui fornisco la chiave primaria è che è conveniente eseguire la maggior parte delle operazioni SQL dal lato client e la mia scelta è sempre stata il tipo intero con incremento automatico.

Il tuo collega ha ragione: usa un numero intero autoincrementante per la tua chiave primaria.

È possibile implementare l'unicità della posta elettronica a livello di applicazione oppure contrassegnare la colonna dell'indirizzo e-mail come univoca e aggiungere un indice su quella colonna.

L'aggiunta del campo come univoco ti costerà il confronto delle stringhe solo quando si inserisce in quella tabella e non quando si eseguono join e controlli dei vincoli di chiave esterna.

Ovviamente, è necessario notare che l'aggiunta di eventuali vincoli all'applicazione a livello di database può rendere l'app non flessibile. Prendi sempre la dovuta considerazione prima di rendere qualsiasi campo "unico" o "non nullo" solo perché la tua applicazione deve essere unica o non vuota.

Usa un GUID come chiave primaria ... in questo modo puoi generarlo dal tuo programma quando esegui un INSERT e non hai bisogno di ottenere una risposta dal server per scoprire qual è la chiave primaria. Sarà anche unico attraverso tabelle e database e non devi preoccuparti di cosa succede se un giorno tronchi la tabella e l'incremento automatico viene ripristinato a 1.

So che è un po 'tardi, ma vorrei aggiungere che le persone abbandonano gli account e-mail e i fornitori di servizi recuperano l'indirizzo consentendo a un'altra persona di usarlo.

Come ha sottolineato @HLGEM "Jsmith@somecompany.com può facilmente appartenere a John Smith un anno e Julia Smith due anni dopo". in questo caso, se John Smith desidera il tuo servizio, devi rifiutare di utilizzare il suo indirizzo e-mail o eliminare tutti i tuoi record relativi a Julia Smith.

Se devi eliminare i record e questi si riferiscono alla storia finanziaria dell'azienda in base alla legge locale, potresti ritrovarti in acqua calda.

Quindi non userei mai dati come indirizzi e-mail, targhe, ecc. Come chiavi primarie perché non importa quanto siano univoci fuori dal tuo controllo e in grado di fornire alcune sfide interessanti che potresti non avere il tempo di affrontare.

Potrebbe essere necessario prendere in considerazione qualsiasi normativa applicabile sulla regolamentazione dei dati. Le e-mail sono informazioni personali e, ad esempio, se i tuoi utenti sono cittadini dell'UE in base al GDPR, possono istruirti sull'eliminazione delle loro informazioni dai tuoi registri (ricorda che ciò vale indipendentemente dal paese in cui ti trovi).

Se è necessario conservare il record stesso nel database per integrità referenziale o motivi storici come l'audit, l'utilizzo di una chiave surrogata consentirebbe di NULL tutti i campi dei dati personali. Questo ovviamente non è facile se i loro dati personali sono la chiave primaria

è possibile migliorare le prestazioni utilizzando la chiave primaria intera.

dovresti usare una chiave primaria intera. se hai bisogno che la colonna e-mail sia univoca, perché non imposti semplicemente un indice univoco su quella colonna?

Se si dispone di un valore non int come chiave primaria, gli inserimenti e i recuperi saranno molto lenti su dati di grandi dimensioni.

chiave primaria dovrebbe essere scelto un attributo statico. Poiché gli indirizzi e-mail non sono statici e possono essere condivisi da più candidati, non è una buona idea usarli come chiave primaria. Inoltre gli indirizzi e-mail sono stringhe di solito di una certa lunghezza che possono essere maggiori di un ID univoco che vorremmo usare [len (indirizzo_email)> len (unique_id)] ​​in modo da richiedere più spazio e, peggio ancora, vengono memorizzati più volte come chiave esterna . E di conseguenza porterà a degradare le prestazioni.

Dipende dal tavolo. Se le righe nella tabella rappresentano gli indirizzi e-mail, l'email è l'ID migliore. In caso contrario, l'e-mail non è un buon ID.

Se si tratta semplicemente di richiedere che l'email sia unica, puoi semplicemente creare un indice univoco con quella colonna.

L'e-mail è un buon candidato all'indice univoco, ma non per la chiave primaria, se si tratta di una chiave primaria, non sarà possibile, ad esempio, modificare l'indirizzo di posta elettronica del contatto. Penso che anche le tue domande di partecipazione saranno più lente.

non utilizzare l'indirizzo e-mail come chiave primaria, mantenere l'e-mail come unica ma non utilizzarla come chiave primaria, utilizzare l'id utente o il nome utente come chiave primaria