Discussion :

[Mikaelo]

Bonjour tous le monde,

Je suis un gros debutant en mySQL, deux jours tout au plus (je suis ingenieur dev en systeme embarque ...), et j'ai une question tres simple :

Le scénario est le suivant:
Je gere une table d'utilisateur classique comme des millions de sites aujourd'hui, c'est a dire avec:
- Nom
- Mail
- pseudo (éventuellement)
- mdp (mot de passe)
- ect ...
- et un ID unique comme PRIMARY_KEY.

Question:
Lorsque vient un user pour se connecter, la majorité des devellopeurs font un
SELECT pseudo, FROM user WHERE pseudo = "toto",
pour ensuite verifier le mot de passe.

J'imagine que dans une tel solution, la base de données parcours la totalité des pseudos et fait un "if" ...

N'est t'il pas plus intelligent de creer a l'enregistrement un identifiant unique, fonction du peudo et mdp (a l'aide d'algo de chiffrement ou autre ) et de s'en servir comme PRIMARY_KEY ? J'imagine qu'une recherche sur une PRIMARY_KEY doit etre plus rapide non ?

Merci

[Ethan 0x21]

Bonsoir,

C'est exa je l'est d'ailleur déjà implémenté, tu pourrais hacher via md5 par exemple lors de la création/(modification mot de passe)/(modification login) un champ indexé dans ta table MySQL via CREATE INDEX.

Puis lors d'une connexion d'un users, tu hash via php le login et le mdp founis, puis tu lance une requete SQL pour récupérer le tuple associé avec le hash founis en paramétre.

Cependant cette méthode ne fonctionne que pour la connexion d'un user, car par exemple pour rechercher des utilisateur dans un formulaire de recherche par exemple, il te manque le mot de passe pour creer les hashs, à moin d'appliquer une politique de login unique (uid) qui permettrai de ce passer simplement des mot de passe pour le haschage.

Cdt

[Mikaelo]

Merci Ethan pour ta reponse, ca fait plaisir de voir que finalement ma tete réfléchi encore un peu.

Pour le login unique sans mots de passe ca ne me plait pas trop.

Pour le probleme de parcours complet en cas de relève de tous les users, tu as raison, mais l'autre solution ne propose de toute facon pas mieux.

Merci, je vais implementer cela ...

[Ethan 0x21]

Mais de rien, n'oublis pas de définir ton post comme résolus pour aider d'autres personnes dans le même cas.

[Exia_]

Bonjour,

Bonsoir,

C'est exa je l'est d'ailleur déjà implémenté, tu pourrais hacher via md5 par exemple lors de la création/(modification mot de passe)/(modification login) un champ indexé dans ta table MySQL via CREATE INDEX.

Puis lors d'une connexion d'un users, tu hash via php le login et le mdp founis, puis tu lance une requete SQL pour récupérer le tuple associé avec le hash founis en paramétre.

Cependant cette méthode ne fonctionne que pour la connexion d'un user, car par exemple pour rechercher des utilisateur dans un formulaire de recherche par exemple, il te manque le mot de passe pour creer les hashs, à moin d'appliquer une politique de login unique (uid) qui permettrai de ce passer simplement des mot de passe pour le haschage.

Cdt

A tu fait un test de performance pour comparer les différences de performance entre le hash pseudo + mdp et le simple pseudo ?

Le simple fait d'ajouter un index sur la colonne pseudo ne suffirait-il pas ? Voir un index sur le pseudo + mdp ?

[Ethan 0x21]

A tu fait un test de performance pour comparer les différences de performance entre le hash pseudo + mdp et le simple pseudo ?

C'est exa, à l'aide du client mysql fournit dans le paquage par défaut du serveur mysql de oracle, pour chaque requêtes effectués il y a un rendu du temps d'execution, la différence n'est pas flagrante pour de petites tables, mais il y a indéniablement une différence entre les deux.

Le simple fait d'ajouter un index sur la colonne pseudo ne suffirait-il pas ? Voir un index sur le pseudo + mdp ?

le probléme en l'occurence ici est qu'il peut y avoir des doublons du au fait que le login n'est pas un uid et que Mikaelo ne semble pas vouloir implémenter une politique du login unique.

De ce fait un index unique n'est-il pas plus optimisé, qu'un index composé de plusieurs colonnes ?