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


234

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.


5
Qu'entendez-vous par «primaire»? Si l'adresse e-mail doit être unique, il s'agit d'une clé et nécessite une contrainte unique. Que vous décidiez de «promouvoir» qu'il soit «principal» est arbitraire, à moins qu'il n'y ait une raison pratique de le faire, par exemple l'optimisation d'un système peu performant.
onedaywhen

7
Si vous souhaitez que votre base de données applique une adresse e-mail unique, créez une colonne avec un index unique, mais ne l'utilisez pas comme clé primaire.
James Westgate

104
@robert Que faire si quelqu'un veut changer son adresse e-mail? Allez-vous également changer toutes les clés étrangères?
systempuntoout

3
@onedaywhen - pratiquement aucune différence, mais la clé primaire sera groupée par défaut, alors qu'un index unique ne le sera pas. Vous voudrez toujours définir la clé primaire qui sera la clé de recherche d'enregistrement unique par défaut, l'index unique applique simplement l'unicité de la colonne sur un index normal
James Westgate

3
@James Westgate: Pour info, il n'y a pas de clustering automatique dans PostgreSQL. Une CLÉ PRIMAIRE est implémentée sur le disque exactement comme un INDEX UNIQUE où tous les champs ne sont PAS NULS.
Matthew Wood

Réponses:


283

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.


11
@Sjoerd: Le problème n'est pas que l'adresse e-mail soit stockée plusieurs fois, bien que ce soit définitivement inefficace, mais peu importe l'espace disque dur aujourd'hui. La plupart des entreprises n'ont pas l'échelle de Google, où cela importerait. Le problème est que l'adresse e-mail ne peut pas être modifiée par la suite, car il s'agit à la fois d'une clé primaire et référencée comme clé étrangère.
Stefan Steiger

@StefanSteiger Qui a dit quoi que ce soit sur l'espace disque dur? Tout ce que vous stockez va prendre de la place dans la RAM.
Jonathan Allen

Au cas où quelqu'un se demanderait, comme je l'ai fait, une clé GUID serait équivalente à une clé de courrier électronique, je pense.
tofutim

178

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


47
+1 pour avoir mentionné le problème de mise à jour en cascade. C'est pourquoi les amis ne permettent à leurs amis d'utiliser que des clés de substitution ;-).
sleske

10
ah, je n'aime pas du tout le dicton ... les clés de substitution peuvent également être la source de problèmes; oui, l'application sera plus robuste aux changements de règles commerciales et / ou d'intégrité, mais les informations peuvent se perdre un peu plus facilement et l'identité des enregistrements devient moins claire. donc je ne recommanderais pas une règle de base ici ...
Unreason

12
@onedaywhen et @jay, ce n'est pas parce que vous pensez qu'il doit être unique qu'il est unique. Et oui, un mari et une femme peuvent être des clients différents. Le fait que vous ne l'ayez pas rencontré auparavant ne signifie pas que cela ne se produira pas. Je l'ai rencontré et cela arrive, c'est pourquoi les courriels ne devraient jamais être considérés comme uniques, que vous le pensiez ou non. C'est le genre d'exigence que vous repoussez, car elle est intrinsèquement erronée.
HLGEM

15
@HLGEM: Je ne veux pas entrer dans un argument sans fin, mais vous ne pouvez pas dire qu'une clé proposée n'est pas unique en fonction d'hypothèses sans connaître le contexte. Par exemple, du point de vue de la compagnie de téléphone, un numéro de téléphone identifie de manière unique un client, par définition. Oui, vous pouvez dire: "Et si deux ou trois personnes pouvaient répondre lorsque vous appelez ce numéro?" Mais ce n'est pas pertinent. Du point de vue de la compagnie de téléphone, il s'agit par définition d'un seul client. (suite ...)
Jay

14
(suite) De même, si vous construisez un système qui est largement concerné par les communications par e-mail - peut-être un système de distribution de messages ou un système de transfert de notification - alors il est probable que, par définition, une adresse e-mail identifie de manière unique un utilisateur. Si plusieurs personnes partagent cette adresse e-mail, cela n'est pas pertinent. Ils sont une destination de message unique, par conséquent, ils sont un seul utilisateur. "Utilisateur" et "client" ne doivent pas nécessairement être synonymes de "personne humaine".
Jay

99

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.


17
Une propriété d'une bonne clé est qu'elle doit être stable mais PAS nécessairement immuable.
onedaywhen

5
@onedaywhen: Ouais! Sinon, pourquoi SQL prendrait-il en charge les mises à jour en cascade?
Bill Karwin

18
si vous avez le choix, optez pour des clés constantes / immuables; moins de travail pour vous sur la route; ce n'est pas parce que SQL prend en charge les mises à jour en cascade que c'est toujours une bonne idée!
Steven A. Lowe

7
@Vincent Malgrat: "mises à jour en cascade ... normalisation des freins db" - je pense que vous avez mal compris le concept de normalisation!
lorsque le

5
@Vincent Malgrat: merci d'avoir confirmé que vous avez en effet mal compris le concept de normalisation. "vous ne devriez pas avoir la même information répétée sur plusieurs lignes" - vouliez-vous vraiment dire "information"?! Une clé composée impliquera généralement des valeurs répétées sur plusieurs lignes. Pour une clé étrangère, les valeurs sont référencées plutôt que "répétées", grande différence. Un domaine à colonne unique avec deux valeurs (par exemple, «Oui» et «Non») aura les mêmes valeurs sur plusieurs lignes dans une table de référence s'il a trois lignes ou plus. C'est vraiment des trucs basiques!
jour, le

64

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.


@Conrad: Bien qu'il souligne que ce n'est pas un PITA si vous avez un moteur qui prend en charge ON UPDATE CASCADE. Ce n'est pas un problème à ce stade du point de vue du code; le seul vrai problème est l'étendue de la mise à jour et la largeur de la clé. L'adresse e-mail peut être un peu trop, mais une MISE À JOUR EN CASCADE pour un code de pays à 2 caractères n'est pas un gros problème.
Matthew Wood

5
@Matthew IMHO c'est toujours un PITA. Par exemple, supposez que lorsque vous avez conçu votre tableau de pays, il n'y avait que deux tableaux qui le référençaient, pas de biggy, mais au fil du temps, il est devenu 20 tableaux chacun avec des centaines de milliers d'enregistrements. Certains avec la référence d'autres sans. Cela fait qu'une seule écriture logique finit par représenter des dizaines de milliers d'écritures, et elle ne parvient pas à toutes les tables car quelqu'un a oublié une référence lors de l'ajout de la table. C'est exactement ce qui m'est arrivé sur une table de code de pays à 2 caractères, je ne vous trompe pas.
Conrad Frix du

@Wood & Conrad: Le pire des cas, c'est quand il n'y a pas de support DB intégré. Ensuite, vous devez écrire du code pour chaque table avec une référence publiée, et c'est juste une douleur et une porte pour les bogues à glisser. Avec les cascades, vous devez juste vous rappeler d'ajouter une clause sur chaque table, pas telle une grosse affaire.
Jay

2
Les avantages 1 et 3 sont des optimisations prématurées, l'avantage 2 est un avantage très mineur et est complètement surmonté par tout outil de requête décent.
Ash

4
@Ash: Il y a une différence entre "l'optimisation" et "l'optimisation prématurée". Mais bon, selon le même raisonnement, tous les inconvénients que j'ai vus mentionner sont des optimisations prématurées. Alors, où cela vous mène-t-il? En ce qui concerne # 2, je trouve que taper des jointures supplémentaires lorsque j'essaie de faire des requêtes ad hoc est une douleur majeure. Les enregistrements ont souvent plusieurs clés étrangères, vous devrez donc peut-être plusieurs jointures pour obtenir des données compréhensibles. Si par "outil de requête décent" vous voulez dire celui qui détermine quelles données vous voulez voir sans que vous le disiez et qui fait comme par magie les jointures pour vous, j'aimerais voir comment cela fonctionne.
Jay

12

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.


Comment le changement d'adresse e-mail entraînerait-il des doublons? À moins que l'utilisateur A ne modifie son adresse e-mail, puis que l'utilisateur B modifie son e-mail pour qu'il corresponde à l'ancienne valeur de l'utilisateur A, et vos mises à jour ne sont pas effectuées en séquence. À distance possible, je suppose.
Jay

2
Une référence de clé étrangère, par définition, contient la valeur de la clé primaire de la ligne à laquelle elle se réfère. Autrement dit, il duplique la valeur de la clé primaire. (Ainsi, la duplication n'est pas causée par la modification de la valeur. Mais la modification est plus difficile en raison de cette duplication et de la contrainte qui l'impose).
meriton

5
+1 pour la ligne "Supposons qu'un fournisseur de messagerie électronique ferme ses portes."
Reddy

Ce n'est pas un problème. La cascade de clés étrangères existe pour résoudre ce problème. Si un utilisateur modifie son e-mail, la modification se répercutera en cascade sur toutes les tables l'utilisant comme clé étrangère.
Rafa

1
@rafa, je vous assure que si vous utilisez des mises à jour en cascade et que tout un fournisseur cesse ses activités ou change de nom (Yahoo.com devient HooYa.com), votre base de données sera verrouillée à tous les utilisateurs pendant des heures et peut-être des jours pendant que cette cascade à travers le système. C'est un problème très valable (et une raison pour laquelle c'est une mauvaise idée d'utiliser des mises à jour en cascade si vous avez une quantité importante de données et que la clé est susceptible de changer.)
HLGEM

12

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 "John@Doe.com", vous ne trouverez pas "john@doe.com".


7
Il convient de mentionner à cet égard que John@Doe.com et john@Doe.com peuvent être la même boîte aux lettres ou peuvent être des boîtes aux lettres différentes et vous n'avez aucun moyen de dire - il n'y a rien dans la spécification pour dire si la partie locale est la casse - sensible.
telent

Il s'agit plus d'un problème général avec l' application d' unicité des adresses e-mail plutôt que de savoir si elles doivent être utilisées comme clés primaires - le même problème existe dans les deux cas. +1 car c'est toujours un point très utile

11

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/my@email.com. 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.


9

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


5

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


1
Je pensais souligner que maintenant que nous avons une cascade, ce n'est pas un problème
malhal

4

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

8
Pourquoi est-ce "mieux"? Des raisons ou des sources?
Sjoerd

20
Pourriez-vous préciser ceci?
Sjoerd

3

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.


3

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.


3

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.


2

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.


1
"Considérez toujours avant d'implémenter l'exigence x simplement parce que votre application a besoin de l'exigence x." - le pire conseil que j'ai lu depuis pas mal de temps.
onedaywhen

Je ne suis pas convaincu par votre "argument" - dans la vraie vie, il y aura souvent des situations où certaines données essentielles (par exemple, un numéro de téléphone) ne seront pas disponibles immédiatement. Si un tel champ est marqué comme NON NUL dans une base de données, il faudra que les utilisateurs polluent les données avec des champs fictifs (comme 123) au lieu de le laisser vide. Il serait plus pratique de laisser l'application gérer les contraintes (et dans ce cas, l'application pourrait marquer un champ vide comme élément d'action).
jrharshath

5
Je suis d'accord que la définition d'un champ "non nul" doit être effectuée avec prudence. Les exigences telles que «nous avons toujours besoin du numéro de téléphone du client» doivent être examinées attentivement. Ne serait-il pas souhaitable parfois de créer un dossier client même si nous ne connaissons pas le numéro de téléphone en ce moment, et d'y revenir plus tard? Mais "ce domaine doit être unique" est une catégorie différente. Je ne peux pas m'imaginer dire "c'est bien que deux employés aient le même numéro de sécurité sociale, nous le découvrirons plus tard." Comment pourriez-vous jamais redresser les données?
Jay

1
Be Wolves: J'ai connu une femme qui n'avait pas son propre numéro de téléphone. Que faites-vous alors?
David Thornley

@DavidThornley On dirait que vous devriez en savoir plus, ou peut-être adapter un comportement plus convivial.
Philip Schiff

2

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.


2
Sauf si vous vous souciez peu ou pas des performances, utilisez un GUID. C'est no-no # 1 si vous construisez un système qui devra évoluer
Micah


3
Dit à la mode Microsoft-Kool-Aid-potable!
Gary Chambers du

2

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, "Jsmith@somecompany.com 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.


2

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


1

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


1

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?


1

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.


1
Non, l'insertion sera plus lente , car vous avez besoin de deux index uniques: un sur la clé primaire générée et un autre sur l'adresse e-mail.
a_horse_with_no_name

1

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.


0

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é.


0

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


0

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.


0

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

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.