Etant donné que j'ai réussi à avoir la table, je cherche maintenant à la modifier afin d'y ajouter des informations spécifiques à l'utilisateur de mon application.

Premier souci : j'ai prévu de lier l'utilisateur à d'autres tables via un user_id. Si je mets cet user_id en clef primaire, vais-je casser jauthdb et/ou jauth ? Pourquoi avoir mis le login (varchar(50)) en clef primaire ?

Sinon, je mettrai un user_id en colonne unique auto-increment à côté. Et puis-je modifier le varchar(50) du password en char(40) sans tout casser aussi ?

Oui, j'aime bien tout casser ;)

Bonjour,

Si je mets cet user_id en clef primaire, vais-je casser jauthdb et/ou jauth ?

oui. le login doit rester la clé primaire.

Pourquoi avoir mis le login (varchar(50)) en clef primaire ?

Pourquoi vouloir toujours utiliser des numéros comme clé primaire ? Un login identifie un utilisateur de manière unique, n'est-ce pas ? donc clé primaire. Et ça apporte beaucoup d'avantage : dans les autres tables, tu as un nom, pas de numéro, tu sais donc tout de suite qui concerne l'enregistrement.

je mettrai un user_id en colonne unique auto-increment à côté.

oui, c'est ce qui est fait dans jCommunity

Et puis-je modifier le varchar(50) du password en char(40) sans tout casser aussi ?

ça dépend ce que tu utilises comme méthode de chiffrement de mot de passe, indiqué dans la conf de jAuth. (et surtout pas de md5..)

Pourquoi avoir mis le login (varchar(50)) en clef primaire ?

Pourquoi vouloir toujours utiliser des numéros comme clé primaire ? Un login identifie un utilisateur de manière unique, n'est-ce pas ? donc clé primaire. Et ça apporte beaucoup d'avantage : dans les autres tables, tu as un nom, pas de numéro, tu sais donc tout de suite qui concerne l'enregistrement.

Ce n'est pas propre en terme de base de données. Cela me fait répéter une chaine de caractères dans mes données ce qui n'est pas forcément ce que je souhaite. De plus, il est plus facile de parcourir des données numériques (et de les comparer) que de parcourir des données sous formes de chaines.

Quid si l'utilisateur souhaite changer de login ? (je sais, ce n'est pas courant, mais dnas mon application par exemple ca ne devrait pas poser de souci).

Bref, je ne suis pas là pour dire que c'est mal, mais utiliser des numéros n'est pas le mal non plus ;)

Pour ce qui concerne le fameux "avantage", je parcours rarement mes tables à l'oeil, et sinon le langage SQL est fait pour ça, une jointure et hop !

je mettrai un user_id en colonne unique auto-increment à côté.

oui, c'est ce qui est fait dans jCommunity

Ok, c'est parti alors !

Et puis-je modifier le varchar(50) du password en char(40) sans tout casser aussi ?

ça dépend ce que tu utilises comme méthode de chiffrement de mot de passe, indiqué dans la conf de jAuth. (et surtout pas de md5..)

Non, non, sha1, il retourne toujours 40 caractères. Ca me permet de gagner 1 (ou 2 je ne sais plus) octet(s) par utilisateur :)