Adresse e-mail unique ou clé primaire?

Je suis novice dans les bases de données. J'ai lu et découvert que ce n'était probablement pas une bonne idée d'utiliser l'adresse e-mail comme clé primaire, car les comparaisons de chaînes sont plus lentes, ce qui affecte les performances dans les jointures complexes et si un e-mail change, je devrais changer toutes les clés étrangères, ce qui nécessite beaucoup. d'effort.

Mais si ma table d'utilisateurs requiert que chaque utilisateur ait une adresse e-mail et que chacune de ces adresses e-mail soit unique, l'ajout d'un index unique dans la colonne e-mail suffira-t-il? Parce que les champs uniques afaik autorisent les valeurs nulles, alors que j'exige que chaque utilisateur ait une adresse e-mail, n'autorisant pas les valeurs nulles. Y a-t-il quelque chose qui me manque ici? Ou je suis censé rendre la colonne e-mail unique et m'assurer lors de la validation des données sur le serveur que l'utilisateur entre une adresse e-mail afin que chaque utilisateur en ait une?

postgresql primary-key unique-constraint

— aandis
source

Que se passe-t-il lorsqu'un utilisateur change son adresse e-mail - comme il changera par exemple le travail

— user151019

Les comparaisons de chaînes ne sont pas seulement plus lentes, les chaînes ont également tendance à être plus grandes que, disons, un entier, et vous pouvez donc en tenir moins sur une page en mémoire, ce qui augmente vos lectures logiques pour les requêtes.

— Nameless One

Réponses:

Distinguons d'abord les clés et les index, la clé fait partie du modèle logique et est souvent implémentée avec un index unique. Vous pouvez cependant créer un index unique sans créer de clé, mais qui ne peut pas être référencé par une clé étrangère.

Une clé candidate est quelque chose qui identifie de façon unique une ligne dans une table, en SQL, l'une des clés candidates est normalement utilisée comme clé primaire (je n'ai jamais vraiment compris pourquoi l'une des ck est considérée comme "meilleure" que les autres, mais c'est une autre histoire), et le ck restant devient des contraintes uniques.

Une contrainte unique peut être utilisée de la même manière qu'une clé primaire. Considérer:

create table A ( x ... not null
               , y ... not null
               , z ... not null
               ,     unique (x)
               ,     primary key (y,z) );

create table B ( x ...
               ,   ...
               ,     foreign key (x) references A (x) );

create table C ( y ...
               , z ...
               ,   ...
               ,     foreign key (y, z) references A (y, z) );

B fait référence à la contrainte unique et C fait référence à la contrainte de clé primaire.

NOT NULL est encore un autre type de contrainte. Dans votre cas, vous pouvez appliquer cela pour le courrier électronique sans le déclarer unique.

Le prochain aspect de votre message concerne la stabilité d'une clé, une clé doit être stable (mais cela ne signifie pas qu'elle ne peut jamais changer, elle n'a pas besoin d'être immuable). Certains SGBD implémentent ON UPDATE CASCADE qui peuvent être utiles pour une telle opération, mais si la clé est distribuée autour de votre modèle, il sera difficile de la mettre à jour.

Dans votre cas, je choisirais probablement une autre clé candidate comme clé primaire et déclarerais que l'email n'est PAS NUL et UNIQUE.

— Lennart
source

Dans SQL Server, vous pouvez référencer un index unique en tant que FK.

— Martin Smith

Je n'ai pas accès à SQL donc je ne peux pas vérifier par moi-même, cela crée-t-il implicitement une contrainte unique lorsque vous créez un index unique?

— Lennart

Non. Une contrainte unique est traitée légèrement différemment et comporte des métadonnées et des restrictions supplémentaires par rapport à un index unique, mais SQL Server autorise l'une ou l'autre à être utilisée dans un FK.

— Martin Smith

C'est un peu étrange alors, les index ne sont même pas mentionnés dans le standard sql alors que les clés en sont une partie centrale. Quoi qu'il en soit, merci pour l'information.

— Lennart

Il convient de noter que s'il y a beaucoup d'enregistrements à clé étrangère dans votre e-mail, la mise à jour de tous ces enregistrements peut prendre un peu de temps lorsque la mise à jour tombe en cascade.

— cimmanon

Oui, avoir un index unique sur la colonne EmailAddress devrait être correct. Le seul problème serait que si quelqu'un a abandonné l'adresse e-mail après s'être inscrit à votre service mais ne vous l'a pas dit, alors celui qui le propriétaire de l'adresse e-mail essaie de s'inscrire. Mais c'est un cas assez rare.

Quant à savoir si un index unique autorise des valeurs nulles qui dépendront de votre plate-forme de base de données. Oracle le fait, SQL Server autorise une seule valeur NULL. Vous pouvez résoudre ce problème en faisant en sorte que la colonne n'autorise pas les valeurs NULL, puis en construisant l'index unique dessus.

— mrdenny
source

Ce n'est pas vrai pour SQL Server. Vous pouvez créer des index avec des whereclauses qui, par exemple, vous permettent d'exclure des NULLvaleurs de l'index.

— Kirk Woll

La déclaration SQL Server allows a single NULL valueest toujours vraie. Il ne dit pas qu'il n'y a aucun moyen d'obtenir plusieurs NULLvaleurs. Je pense que le répondeur essayait de garder la réponse simple et de ne pas expliquer les détails supplémentaires (comme filtré indexé).

— Brandon

Oui, j'aurais pu plonger le lapin dans son ensemble d'index filtrés, mais une question simple nécessite généralement une réponse simple. Sans plateforme ni version de base de données, je garde mes réponses génériques.

— mrdenny

Avoir l'index unique sur EmailAddress est très bien.

Comme vous avez déjà indiqué qu'il y a une validation dans votre application pour avoir l'adresse e-mail comme champ obligatoire, je dirais que l'autre validation proviendrait de la base de données n'accepte pas un utilisateur sans adresse e-mail et empêche également la duplication d'entrées et ces validations sera imposé avec cet index unique.

Comme indiqué dans d'autres réponses pour SQL Server, vous devez faire en sorte qu'une colonne n'autorise pas la valeur nulle avant de créer des index uniques.

— vijayp
source