Utiliser l'adresse courriel comme clé principale?

l'adresse e-mail est-elle un mauvais candidat pour le primaire par rapport à l'augmentation automatique des numéros?

notre application web a besoin d'une adresse de courriel unique dans le système. Donc, j'ai pensé à utiliser l'adresse e-mail comme clé principale. Cependant mon collègue suggère que la comparaison de chaîne sera plus lente que la comparaison d'entier.

Est-ce une raison valable pour ne pas utiliser le courriel comme clé primaire?

nous utilisons PostgreSQL .

212
demandé sur giannis christofakis 2010-09-27 17:12:21

24 réponses

la comparaison de chaîne 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 en utilisant l'adresse e-mail. Cela 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 sera l'adresse e-mail. Cela signifie que vous stockez l'adresse e-mail plusieurs fois.

264
répondu Sjoerd 2010-09-27 13:17:57

je vais également souligner que le courriel est un mauvais choix pour faire un domaine unique, Il ya des gens et même de petites entreprises qui partagent une adresse courriel. Et comme les numéros de téléphone, les e-mails peuvent être réutilisés. Jsmith@somecompany.com 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 que, comme les clés, alors vous aurez à mettre à jour les autres tables aussi bien qui peut être tout à fait un coup de performance quand une entreprise de client entier change leurs e-mails (ce que j'ai vu se produire.)

165
répondu HLGEM 2012-03-22 19:24:24

la clé primaire doit être uniques et constante

les adresses email changent comme les saisons. Utile comme une clé secondaire pour la recherche, mais un mauvais choix pour la clé primaire.

93
répondu Steven A. Lowe 2010-09-27 13:31:13

inconvénients de l'utilisation d'une adresse e-mail comme clé principale:

  1. ralentis en faisant les jointures.

  2. tout autre enregistrement avec une clé étrangère affichée a maintenant une plus grande valeur, prenant plus d'espace disque. (Étant donné le coût de l'espace disque aujourd'hui, c'est probablement une question triviale, sauf dans la mesure où le dossier maintenant plus de temps pour lire. See #1.)

  3. An l'adresse de courriel pourrait changer, ce qui oblige tous les enregistrements utilisant cette clé étrangère à être mis à jour. Comme l'adresse e-mail ne change pas souvent, le problème de performance est probablement mineur. Le plus gros problème est que vous devez vous assurer de pourvoir à elle. 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 supporte "ON update cascade", c'est un problème mineur.

avantages de l'utilisation du courrier électronique adresse comme clé primaire:

  1. , Vous pouvez être en mesure d'éliminer complètement certaines jointures. Si tout ce dont vous avez besoin à partir du "master record" 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, puis vous l'avez déjà et que la jointure est inutile. Que cela vous aide ou non dépend de la fréquence à laquelle cette situation se présente.

  2. quand vous êtes en faisant des requêtes ad hoc, il est facile pour un être humain de voir quel master record est référencé. Cela peut être d'une grande aide lorsqu'on essaie d'identifier les problèmes de données.

  3. vous aurez presque certainement besoin d'un index sur l'adresse e-mail de toute façon, donc en faire la clé primaire élimine un index, améliorant ainsi la performance des inserts car ils ont maintenant un seul index à mettre à jour au lieu de deux.

dans mon humble opinion, ce n'est pas un slam-dunk. J'ai tendance à préférer utiliser des clés naturelles quand une pratique est disponible parce qu'ils sont juste plus faciles à travailler avec, et les désavantages ont tendance à ne pas beaucoup d'importance dans la plupart des cas.

61
répondu Jay 2010-09-27 15:04:39

C'est assez mauvais. Supposons qu'un fournisseur de courrier électronique cesse ses activités. Les utilisateurs voudront alors modifier leur courriel. Si vous avez utilisé l'e-mail comme clé primaire, toutes les clés étrangères pour les utilisateurs de dupliquer cet e-mail, le rendant très difficile à changer ...

... et je n'ai même pas commencé à parler de performance.

11
répondu meriton 2010-09-27 13:23:27

Je ne sais pas si cela pourrait être un problème dans votre configuration, mais selon vos RDBMS les valeurs d'une colonne pourraient être sensible à la casse . Les docs PostgreSQL disent:"Si vous déclarez une colonne comme clé UNIQUE ou primaire, l'index généré implicitement est sensible à la casse". En d'autres termes, si vous acceptez l'entrée de l'utilisateur pour une recherche dans une table avec le courrier électronique comme clé principale, et l'utilisateur fournit "John@Doe.com", vous ne trouverez pas "john@doe.com".

9
répondu xlttj 2010-09-28 06:33:57

personne ne semble avoir mentionné un problème possible que les adresses électroniques pourraient être considérées comme privées. Si l'adresse email est la clé principale, une URL de page de profil ressemblera probablement quelque chose comme ..../Users/my@email.com . Que faire si vous ne voulez pas exposer l'utilisateur à l'adresse de courriel? Vous devez trouver un autre moyen d'identifier l'utilisateur, éventuellement par une valeur entière unique pour faire des URLs comme ..../Users/1 . Alors vous finiriez avec une valeur entière unique après tout.

9
répondu Simen Echholt 2010-10-03 10:45:04

À la logique niveau , l'e-mail est la clé naturelle. Au niveau physique , é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 rendement mentionnés par d'autres.

pour cette raison, le dessin peut être adapté. La clé naturelle devient la clé alternative (UNIQUE, pas NULL), et vous utilisez une clé de substitution / artificielle / technique comme la clé primaire, qui peut être un auto-incrément dans votre cas.

systempuntoout demandé,

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

C'est à ça que sert cascade .

une autre raison d'utiliser un substitut numérique clé comme clé primaire est liée à l'indexation des travaux dans votre plate-forme. Dans InnoDB de MySQL, par exemple, tous les index d'une table ont la clé primaire prédéfinie, donc vous voulez que le PK soit aussi petit que possible (pour les sakes de vitesse et de taille). Aussi lié à cela, InnoDB est plus rapide quand la clé primaire est stockée dans la séquence, et une chaîne de caractères ne serait pas utile là.

une autre chose à prendre en considération lors de l'utilisation d'une chaîne comme une clé alternative, est que l'utilisation d'une le hachage de la corde réelle que vous voulez pourrait être plus rapide, sautant des choses comme des cas supérieurs et inférieurs de certaines lettres. (J'ai atterri ici en cherchant une référence pour confirmer ce que je viens de dire; je cherche toujours...)

7
répondu Rafa 2012-09-06 11:50:19

oui, il est préférable d'utiliser un entier à la place. vous pouvez également définir votre colonne email comme contrainte unique.

comme ceci:

CREATE TABLE myTable(
    id integer primary key,
    email text UNIQUE
);
4
répondu ibram 2010-09-27 13:15:15

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

4
répondu Lone Coder 2010-10-03 02:00:50

une autre raison pour laquelle la clé primaire entière est meilleure est quand vous vous référez à l'adresse e-mail dans une table différente. Si l'adresse elle-même est une clé primaire, alors dans une autre table vous devez l'utiliser comme clé. Si vous stockez des adresses e-mail plusieurs fois.

3
répondu klew 2010-09-27 13:18:45

Je ne suis pas très familier avec postgres. Les clés primaires sont un grand sujet. J'ai vu d'excellentes questions et réponses sur ce site (stackoverflow.com).

je pense que vous pourriez avoir une meilleure performance en ayant une clé numérique primaire et utiliser un INDEX UNIQUE sur la colonne de courrier électronique. Les courriels ont tendance à varier en longueur et peuvent ne pas être appropriés pour l'index de la clé primaire.

lire ici et ici.

3
répondu Saif Khan 2017-05-23 12:18:10

votre collègue a raison: utilisez un entier d'auto-intégration pour votre clé primaire.

vous pouvez implémenter l'unicité du courriel soit au niveau de l'application, soit vous pouvez marquer votre colonne d'adresse courriel comme unique, et Ajouter un index sur cette colonne.

L'ajout du champ en tant qu'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 de contraintes de clé étrangère.

Bien sûr, vous devez noter que l'ajout de contraintes de votre application au niveau base de données peut entraîner l'application de devenir inflexible. Toujours prendre en considération avant de faire un champ "unique" ou "non null" juste parce que votre application a besoin qu'il soit unique ou non vide.

2
répondu jrharshath 2010-09-27 13:19:00

utilisez un guide comme clé primaire... de cette façon, vous pouvez générer à partir de votre programme lorsque vous effectuez une INSERTION et vous n'avez pas besoin d'obtenir une réponse du serveur pour savoir ce que la clé primaire est. Il sera également unique accross tables et bases de données et vous n'avez pas à vous soucier de ce qui se passe si vous tronquez la table un jour et l'auto-incrément obtient réinitialisé à 1.

2
répondu JoelFan 2010-09-27 20:54:16

personnellement, je n'utilise aucune information pour la clé primaire lors de la conception de la base de données, parce qu'il est très probable que je pourrais avoir besoin de modifier toute information plus tard. La seule raison pour laquelle je fournis la clé primaire est, il est pratique de faire la plupart des opérations SQL côté client, et mon choix pour cela a toujours été auto-increment type entier.

2
répondu tia 2010-09-28 02:42:59

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

comme @HLGEM l'a souligné "Jsmith@somecompany.com peut facilement appartenir à John Smith un an et Julia Smith deux ans plus tard."dans ce cas, si John Smith veut votre service, vous devez refuser d'utiliser son adresse e-mail ou supprimer tous vos dossiers concernant Julia Smith.

Si vous devez supprimer des enregistrements et ils se rapportent à l'histoire financière de l'entreprise selon la législation locale, vous pourriez vous retrouver dans l'eau chaude.

donc je n'utiliserais jamais des données comme des adresses e-mail, des plaques d'immatriculation, etc. comme des clés primaires parce que peu importe comment unique ils semblent être hors de votre contrôle et peut fournir certains défis intéressants que vous ne pouvez pas avoir le temps de traiter.

2
répondu Robert 2012-04-02 09:20:03

vous pouvez augmenter la performance en utilisant la clé primaire entière.

1
répondu xport 2010-09-27 13:14:47

vous devez utiliser une clé primaire entière. si vous avez besoin de la colonne email pour être unique, pourquoi ne pas simplement définir un index unique sur cette colonne?

1
répondu oezi 2010-09-27 13:16:12

si vous avez une valeur non int comme clé primaire, les insertions et les extractions seront très lentes sur les données volumineuses.

1
répondu Amareswar 2010-09-27 14:37:52

cela dépend de la table. Si les lignes dans votre tableau représentent des adresses email, alors email est le meilleur ID. Si ce n'est pas le cas, le courriel n'est pas une bonne pièce d'identité.

0
répondu Lajos Arpad 2010-09-27 19:07:05

S'il s'agit simplement d'exiger que le courriel soit unique, alors vous pouvez créer un index unique avec cette colonne.

0
répondu Micah 2010-09-27 21:06:42

e-mail est un bon candidat index unique, mais pas pour la clé primaire, si c'est une clé primaire, vous ne serez pas en mesure de changer l'adresse e-mail de la personne-ressource par exemple. Je pense que vos join querys seront plus lents aussi.

0
répondu Chocolim 2010-10-04 18:21:55
La clé primaire

doit être choisie comme attribut statique. Puisque les adresses e-mail ne sont pas statiques et peuvent être partagées par plusieurs candidats, il n'est donc pas une bonne idée de les utiliser comme clé principale. De plus, les adresses e-mail sont des chaînes généralement d'une certaine longueur qui peut être supérieure à l'id unique que nous aimerions utiliser[len(email_address)>len(unique_id)] de sorte qu'il faudrait plus d'espace et même pire ils sont stockés plusieurs fois comme clé étrangère. Et par conséquent, conduire à dégrader la performance.

0
répondu user2719152 2015-12-24 06:03:41

n'utilisez pas l'adresse courriel comme clé principale, conservez l'adresse courriel comme unique mais ne l'utilisez pas comme clé principale, utilisez l'ID utilisateur ou le nom d'utilisateur comme clé principale

0
répondu Nikki 2017-11-10 14:18:15