Les jointures sont mes amies, merci :)

[quote="macgawel"]même si perso je rajouterais l'identifiant par sécurité : en cas de changement de pseudo tu pourras répercuter dans ta table[/quote]
Voilà LE argument pour rester normalisé.

Un identifiant d'une table doit TOUJOURS être invisible pour l'utilisateur. Tout ceci pour qu'il ne demande jamais à ce qu'il soit changé, et que l'on ai donc jamais à modifier les identifiants d'une table, et risquer de perdre les références.
De plus, les moteurs actuels sont suffisemment performant pour qu'une jointure entre 2 tables ne soient pas un gouffre de performances.

Ca dépend...

[i]En théorie[/i] on doit utiliser l'identifiant.
[i]En pratique[/i], a priori tu vas faire beaucoup de lectures sur ta table TCHAT et le pseudo est (relativement) invariant.

=> Tu peux [i]dénormaliser[/i] ta base, et mettre le pseudo dans TCHAT (même si perso je rajouterais l'identifiant par sécurité : en cas de changement de pseudo tu pourras répercuter dans ta table)

Moi je fonctionne toujours par identifiant.

Bonjour,

J'ai une question existentielle qui me trotte dans la tête... je vous la pose :p

Qu'est ce qui est le plus conseillé dans le cas où il existe déjà une table MEMBRE contenant, entre autre, le pseudo et l'id du membre concerné ?
Avoir une table TCHAT où il existe un champs pseudo (VARCHAR) qui permet donc de repérer facilement qui est l'auteur de l'un ou l'autre message sur un tchat
[b]OU[/b]
Avoir cette même table TCHAT mais changer le champs pseudo par id_membre (INT) qui permettrait d'identifier l'auteur de l'un ou l'autre message en faisant une autre requete sur la table MEMBRE ?

Bref, est-ce que c'est mieux d'utiliser deux requêtes mais de stocker dans une table une petite série de chiffre plutôt qu'une chaine de 20 caractères [b]OU[/b] ou stocker directement une petite chaine de caractère sans devoir lancer une requête sur une autre table pour savoir à quoi correspond le champs ?

Je sais pas si je me fais bien comprendre... :D