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

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 firebase database en utilisant l’adresse de messagerie. Il est important que vous ayez des requêtes complexes avec plusieurs jointures.

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

Je ferai également remarquer que le courrier électronique est un mauvais choix pour créer un domaine unique, il y a des gens et même de petites entresockets qui partagent une adresse électronique. Et comme les numéros de téléphone, les 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 emails est qu’ils changent fréquemment. Si vous vous connectez à d’autres tables avec cette clé, vous devrez également mettre à jour les autres tables, ce qui peut être une véritable perte de performance lorsqu’une entreprise cliente entière change ses emails (ce que j’ai vu).

la clé primaire doit être unique et constante

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

Inconvénients d’utiliser 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 supérieure, ce qui prend plus d’espace disque. (Compte tenu du coût de l’espace disque aujourd’hui, il s’agit probablement d’un problème sortingvial, sauf dans la mesure où la lecture de l’enregistrement est maintenant plus longue. Voir # 1.)

3. Une adresse e-mail peut changer, ce qui oblige tous les enregistrements utilisant cette clé à être mis à jour. Comme l’adresse électronique ne change pas souvent, le problème de performance est probablement mineur. Le plus gros problème est que vous devez vous assurer de le prévoir. Si vous devez écrire le code, c’est plus de travail et introduit la possibilité de bogues. Si votre moteur de firebase database prend en charge “on update cascade”, c’est un problème mineur.

Avantages de l’utilisation de l’adresse électronique comme clé primaire:

1. Vous pourrez peut-être éliminer complètement certaines jointures. Si tout ce dont vous avez besoin à partir de “la fiche” est l’adresse email, alors avec une clé entière abstraite, vous devrez faire une jointure pour la récupérer. Si la clé est l’adresse électronique, vous l’avez déjà et la jointure est inutile. Que cela vous aide 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 quelle fiche est référencée. Cela peut être d’une grande aide lorsque vous essayez de détecter des problèmes de données.

3. Vous aurez certainement besoin d’un index sur l’adresse e-mail, ce qui en fait la clé principale élimine un index, améliorant ainsi les performances des insertions car elles ne disposent désormais que d’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 lorsque celles-ci sont pratiques, car elles sont simplement plus faciles à utiliser et les inconvénients ne sont pas vraiment importants dans la plupart des cas.

C’est pas mal. Supposons qu’un fournisseur de messagerie cesse ses activités. Les utilisateurs voudront alors changer leur adresse 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 rend très difficile le changement …

… et je n’ai même pas commencé à parler de considérations de performance.

Je ne sais pas si cela pourrait ê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 une entrée utilisateur pour une recherche dans une table avec un courrier électronique en tant que clé primaire et que l’utilisateur fournit “[email protected]”, vous ne trouverez pas “[email protected]”.

Personne ne semble avoir mentionné un problème éventuel que les adresses électroniques pourraient être considérées comme privées. Si l’adresse e-mail est la clé primaire, l’URL de la page de profil ressemblera probablement à ..../Users/[email protected] . Que faire si vous ne souhaitez pas exposer l’adresse e-mail de l’utilisateur? Vous devrez trouver un autre moyen d’identifier l’utilisateur, éventuellement par une valeur entière unique pour créer des URL telles que ..../Users/1 . Ensuite, vous obtiendrez une valeur entière unique après tout.

Au niveau logique , l’e-mail est la clé naturelle. Au niveau physique , étant donné que vous utilisez une firebase database 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 un incrément automatique dans votre cas.

systempuntoout demandé,

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

C’est ce que la cascade est pour.

Une autre raison d’utiliser une clé de substitution numérique en tant que clé primaire est liée au fonctionnement de l’indexation dans votre plate-forme. Dans InnoDB de MySQL, par exemple, la clé primaire est pré-attachée à tous les index d’une table. Vous voulez donc que la PK soit aussi petite que possible (pour la vitesse et la taille). Aussi lié à cela, InnoDB est plus rapide lorsque la clé primaire est stockée en séquence, et une chaîne ne serait pas utile là-bas.

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

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 ); 

Oui, c’est une mauvaise clé primaire car vos utilisateurs voudront mettre à jour leurs adresses de messagerie.

Une autre raison pour laquelle la clé primaire entière est meilleure est lorsque vous faites référence à une adresse électronique dans une table différente. Si address lui-même est une clé primaire, vous devez l’utiliser comme clé dans une autre table. Ainsi, vous stockez les adresses de messagerie plusieurs fois.

Je ne suis pas trop familier avec les 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 de meilleures performances en ayant une clé primaire numérique et en utilisant un INDEX UNIQUE sur la colonne email. Les e-mails ont tendance à varier en longueur et peuvent ne pas être appropriés pour l’indice de clé primaire.

certains lisent ici et ici.

Votre collègue a raison: utilisez un entier auto-incrémenté pour votre clé primaire.

Vous pouvez implémenter l’unicité du courrier électronique au niveau de l’application ou marquer votre colonne d’adresse de messagerie comme unique et append un index sur cette colonne.

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

Bien entendu, vous devez noter que l’ajout de contraintes à votre application au niveau de la firebase database peut rendre votre application peu flexible. Prenez toujours en considération avant de rendre un champ “unique” ou “non nul” simplement parce que votre application en a besoin pour être 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 une INSERT et vous n’avez pas besoin d’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.

Personnellement, je n’utilise aucune information pour la clé primaire lors de la conception de la firebase database, car il est fort probable que je devrais modifier des informations ultérieurement. La seule raison pour laquelle je fournis une clé primaire est la commodité de faire la plupart des opérations SQL côté client, et mon choix a toujours été le type entier à incrémentation automatique.

Je sais que c’est un peu tardif mais j’aimerais append que les gens abandonnent les comptes de messagerie et que 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 veut 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.

Ainsi, je n’utiliserais jamais les données comme les adresses e-mail, les plaques d’immasortingculation, etc. comme clés primaires, car elles semblent être hors de contrôle, même si elles semblent uniques et peuvent présenter des défis intéressants que vous n’avez peut-être pas le temps de gérer.

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 email soit unique, pourquoi ne définissez-vous pas simplement 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 les données volumineuses.

Cela dépend de la table. Si les lignes de votre table représentent des adresses électroniques, le courrier électronique est le meilleur identifiant. Sinon, le courrier électronique n’est pas une bonne identification.

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

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 modifier l’adresse email du contact par exemple. Je pense que vos requêtes de jointure seront également plus lentes.

clé primaire doit être choisi un atsortingbut statique. Étant donné que les adresses de messagerie ne sont pas statiques et peuvent être partagées par plusieurs candidats, il est déconseillé de les utiliser comme clé primaire. De plus, les adresses e-mail sont généralement des chaînes d’une certaine longueur qui peuvent être supérieures à l’identifiant unique que nous voudrions utiliser [len (email_address)> len (unique_id)]. . Et par conséquent, cela entraînera une dégradation des performances.

n’utilisez pas l’adresse électronique comme clé primaire, conservez le courrier électronique comme unique, mais ne l’utilisez pas comme clé primaire, utilisez l’ID utilisateur ou le nom d’utilisateur comme clé primaire