Utiliser l'adresse e-mail comme clé primaire?

L'adresse e-mail est-elle un mauvais candidat pour le primaire par rapport aux numéros à incrémentation automatique?

Notre application Web a besoin que l'adresse e-mail soit unique dans le système. J'ai donc pensé à utiliser l'adresse e-mail comme clé primaire. Cependant, mon collègue suggère que la comparaison de chaînes sera plus lente que la comparaison d'entiers.

Est-ce une raison valable de ne pas utiliser le courrier électronique comme clé primaire?

Nous utilisons PostgreSQL.

La comparaison de chaînes est plus lente que la comparaison int. Cependant, cela n'a pas d'importance si vous récupérez simplement un utilisateur de la base de données à l'aide de l'adresse e-mail. Peu importe si vous avez des requêtes complexes avec plusieurs jointures.

Si vous stockez des informations sur les utilisateurs dans plusieurs tables, les clés étrangères de la table des utilisateurs seront l'adresse de messagerie. Cela signifie que vous stockez l'adresse e-mail plusieurs fois.

Je soulignerai également que l'e-mail est un mauvais choix pour créer un champ unique, il y a des gens et même des petites entreprises qui partagent une adresse e-mail. Et comme les numéros de téléphone, e mails peuvent être réutilisés. [email protected] peut facilement appartenir à John Smith un an et Julia Smith deux ans plus tard.

Un autre problème avec les e-mails est qu'ils changent fréquemment. Si vous vous joignez à d'autres tables avec cela comme clé, vous devrez également mettre à jour les autres tables, ce qui peut être tout à fait un problème de performance lorsqu'une entreprise cliente entière modifie ses e-mails (ce que j'ai vu se produire).

la clé primaire doit être unique et constante

les adresses e-mail changent au fil des saisons. Utile comme clé secondaire pour la recherche, mais mauvais choix pour la clé primaire.

Inconvénients de l'utilisation d'une adresse e-mail comme clé primaire:

1. Plus lent lors des jointures.

2. Tout autre enregistrement avec une clé étrangère publiée a désormais une valeur plus élevée, occupant plus d'espace disque. (Étant donné le coût de l'espace disque aujourd'hui, il s'agit probablement d'un problème trivial, sauf dans la mesure où l'enregistrement prend plus de temps à lire. Voir # 1.)

3. Une adresse e-mail peut changer, ce qui force la mise à jour de tous les enregistrements l'utilisant comme clé étrangère. Comme l'adresse e-mail ne change pas si souvent, le problème de performances est probablement mineur. Le plus gros problème est que vous devez vous en assurer. Si vous devez écrire le code, c'est plus de travail et introduit la possibilité de bugs. Si votre moteur de base de données prend en charge "en cascade de mise à jour", il s'agit d'un problème mineur.

Avantages d'utiliser l'adresse e-mail comme clé primaire:

1. Vous pourrez peut-être éliminer complètement certaines jointures. Si tout ce dont vous avez besoin dans "l'enregistrement principal" est l'adresse e-mail, alors avec une clé entière abstraite, vous devrez faire une jointure pour la récupérer. Si la clé est l'adresse e-mail, vous l'avez déjà et la jointure n'est pas nécessaire. Que cela vous aide ou non dépend de la fréquence à laquelle cette situation se présente.

2. Lorsque vous effectuez des requêtes ad hoc, il est facile pour un être humain de voir quel enregistrement principal est référencé. Cela peut être d'une grande aide lors de la recherche de problèmes de données.

3. Vous aurez presque certainement besoin d'un index sur l'adresse e-mail de toute façon, ce qui en fait la clé primaire élimine un index, améliorant ainsi les performances des insertions car ils n'ont désormais qu'un seul index à mettre à jour au lieu de deux.

À mon humble avis, ce n'est pas un slam-dunk de toute façon. J'ai tendance à préférer utiliser des clés naturelles lorsqu'elles sont pratiques, car elles sont simplement plus faciles à utiliser et les inconvénients ont généralement peu d'importance dans la plupart des cas.

C'est assez mauvais. Supposons qu'un fournisseur de messagerie électronique ferme ses portes. Les utilisateurs voudront alors changer leur e-mail. Si vous avez utilisé l'e-mail comme clé primaire, toutes les clés étrangères pour les utilisateurs dupliqueront cet e-mail, ce qui le rendra assez difficile à changer ...

... et je n'ai même pas commencé à parler de considérations de performances.

Je ne sais pas si cela peut être un problème dans votre configuration, mais en fonction de votre SGBDR, les valeurs d'une colonne peuvent être sensibles à la casse . Les documents PostgreSQL disent: "Si vous déclarez une colonne comme UNIQUE ou PRIMARY KEY, l'index généré implicitement est sensible à la casse". En d'autres termes, si vous acceptez l'entrée d'utilisateur pour une recherche dans une table avec le courrier électronique comme clé primaire et que l'utilisateur fournit "[email protected]", vous ne trouverez pas "[email protected]".

Personne ne semble avoir mentionné un problème possible que les adresses e-mail pourraient être considérées comme privées. Si l'adresse e-mail est la clé primaire, une URL de page de profil ressemblera probablement à quelque chose ..../Users/[email protected]. Que faire si vous ne souhaitez pas révéler l'adresse e-mail de l'utilisateur? Il faudrait trouver une autre façon d'identifier l'utilisateur, éventuellement par une valeur entière unique pour faire des URL comme ..../Users/1. Ensuite, vous vous retrouveriez avec une valeur entière unique après tout.

Au niveau logique , l'e-mail est la clé naturelle. Au physique niveau , étant donné que vous utilisez une base de données relationnelle, la clé naturelle ne correspond pas bien à la clé primaire. La raison en est principalement les problèmes de performance mentionnés par d'autres.

Pour cette raison, le design peut être adapté. La clé naturelle devient la clé alternative (UNIQUE, NOT NULL), et vous utilisez une clé de substitution / artificielle / technique comme clé primaire, qui peut être une incrémentation automatique dans votre cas.

a demandé systempuntoout,

Et si quelqu'un veut changer son adresse e-mail? Allez-vous également changer toutes les clés étrangères?

C'est ce que cascade sert la .

Une autre raison d'utiliser une clé de substitution numérique comme clé primaire est liée au fonctionnement de l'indexation dans votre plateforme. Dans InnoDB de MySQL, par exemple, tous les index d'une table ont la clé primaire pré-suspendue, donc vous voulez que le PK soit aussi petit que possible (pour des raisons de vitesse et de taille). Également lié à cela, InnoDB est plus rapide lorsque la clé primaire est stockée dans l'ordre, et une chaîne n'y aiderait pas.

Une autre chose à prendre en considération lors de l'utilisation d'une chaîne comme clé alternative est que l'utilisation d'un hachage de la chaîne réelle que vous souhaitez peut être plus rapide, en sautant des choses comme les majuscules et les minuscules de certaines lettres. (J'ai en fait atterri ici en cherchant une référence pour confirmer ce que je viens de dire; toujours à la recherche ...)

Oui, c'est une mauvaise clé primaire car vos utilisateurs voudront mettre à jour leurs adresses e-mail.

oui, il vaut mieux utiliser un entier à la place. vous pouvez également définir votre colonne de messagerie comme contrainte unique.

comme ça:

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

Une autre raison pour laquelle la clé primaire entière est meilleure est lorsque vous faites référence à l'adresse e-mail dans un tableau différent. Si l'adresse elle-même est une clé primaire, dans une autre table, vous devez l'utiliser comme clé. Vous stockez donc les adresses e-mail plusieurs fois.

Je ne connais pas trop les postgres. Les clés primaires sont un gros sujet. J'ai vu d'excellentes questions et réponses sur ce site (stackoverflow.com).

Je pense que vous pouvez avoir de meilleures performances en ayant une clé primaire numérique et en utilisant un INDEX UNIQUE sur la colonne e-mail. Les e-mails ont tendance à varier en longueur et peuvent ne pas convenir à l'index de clé primaire.

un peu de lecture ici et ici.

Personnellement, je n'utilise aucune information pour la clé primaire lors de la conception de la base de données, car il est très probable que je devrais modifier des informations ultérieurement. La seule raison pour laquelle je fournis la clé primaire est qu'il est pratique d'effectuer la plupart des opérations SQL du côté client, et mon choix a toujours été de type entier à incrémentation automatique.

Votre collègue a raison: utilisez un entier à incrémentation automatique pour votre clé primaire.

Vous pouvez implémenter l'unicité des e-mails soit au niveau de l'application, soit vous pouvez marquer votre colonne d'adresse e-mail comme unique et ajouter un index sur cette colonne.

L'ajout du champ comme unique vous coûtera la comparaison des chaînes uniquement lors de l'insertion dans cette table, et non lors de l'exécution des jointures et des vérifications des contraintes de clé étrangère.

Bien sûr, vous devez noter que l'ajout de contraintes à votre application au niveau de la base de données peut rendre votre application inflexible. Prenez toujours en considération avant de rendre un champ "unique" ou "non nul" simplement parce que votre application a besoin qu'il soit unique ou non vide.

Utilisez un GUID comme clé primaire ... de cette façon, vous pouvez le générer à partir de votre programme lorsque vous effectuez un INSERT et vous n'avez pas besoin d'obtenir une réponse du serveur pour savoir quelle est la clé primaire. Il s'agira également de tables et de bases de données uniques et vous n'avez pas à vous soucier de ce qui se passe si vous tronquez la table un jour et que l'incrémentation automatique est réinitialisée à 1.

Je sais que c'est un peu une entrée tardive mais je voudrais ajouter que les gens abandonnent les comptes de messagerie et les fournisseurs de services récupèrent l'adresse permettant à une autre personne de l'utiliser.

Comme l'a souligné @HLGEM, "[email protected] peut facilement appartenir à John Smith un an et Julia Smith deux ans plus tard." dans ce cas, si John Smith souhaite votre service, vous devez soit refuser d'utiliser son adresse e-mail, soit supprimer tous vos enregistrements relatifs à Julia Smith.

Si vous devez supprimer des enregistrements et qu'ils se rapportent à l'historique financier de l'entreprise en fonction de la législation locale, vous pourriez vous retrouver dans l'eau chaude.

Je n'utiliserais donc jamais des données telles que des adresses e-mail, des plaques d'immatriculation, etc. comme clés primaires, car peu importe leur caractère unique, elles échappent à votre contrôle et peuvent présenter des défis intéressants que vous n'aurez peut-être pas le temps de traiter.

Vous devrez peut-être prendre en compte toute législation applicable en matière de réglementation des données. L'e-mail est une information personnelle, et si vos utilisateurs sont des citoyens de l'UE par exemple, alors en vertu du RGPD, ils peuvent vous demander de supprimer leurs informations de vos dossiers (rappelez-vous que cela s'applique quel que soit le pays dans lequel vous êtes basé).

Si vous devez conserver l'enregistrement lui-même dans la base de données pour l'intégrité référentielle ou pour des raisons historiques telles que l'audit, l'utilisation d'une clé de substitution vous permettrait de simplement NULL tous les champs de données personnelles. Ce n'est évidemment pas aussi facile si leurs données personnelles sont la clé primaire

vous pouvez augmenter les performances en utilisant une clé primaire entière.

vous devez utiliser une clé primaire entière. si vous avez besoin que la colonne e-mail soit unique, pourquoi ne pas simplement définir un index unique sur cette colonne?

Si vous avez une valeur non int comme clé primaire, les insertions et les récupérations seront très lentes sur des données volumineuses.

la clé primaire doit être choisie comme un attribut statique. Étant donné que les adresses e-mail ne sont pas statiques et peuvent être partagées par plusieurs candidats, il n'est donc pas judicieux de les utiliser comme clé primaire. De plus, les adresses e-mail sont des chaînes généralement d'une certaine longueur qui peut être supérieure à l'identifiant unique que nous aimerions utiliser [len (email_address)> len (unique_id)], ce qui nécessiterait plus d'espace et, pire encore, elles sont stockées plusieurs fois en tant que clé étrangère . Et par conséquent cela conduira à dégrader les performances.

Cela dépend de la table. Si les lignes de votre tableau représentent des adresses e-mail, l'e-mail est le meilleur ID. Sinon, l'e-mail n'est pas une bonne pièce d'identité.

S'il s'agit simplement d'exiger que l'e-mail soit unique, vous pouvez simplement créer un index unique avec cette colonne.

L'email est un bon candidat d'index unique, mais pas pour la clé primaire, s'il s'agit d'une clé primaire, vous ne pourrez pas changer l'adresse email du contact par exemple. Je pense que vos requêtes de jointure seront également plus lentes.

ne pas utiliser l'adresse e-mail comme clé primaire, conserver l'e-mail comme unique mais ne pas l'utiliser comme clé primaire, utiliser l'ID utilisateur ou le nom d'utilisateur comme clé primaire