salut à tous,
 
 
Avec des collègues on se posait la question sur quelle serait la méthode la plus rapide/la moins lourde entre 2 cas. Je vous expose la situation :
 
1er cas : On a 3 tables, une table 'users' (id_user, fname, lname) et une table 'user_version' (id_user, id_version) qui serait une table de liaison vers une table 'version' (id_version, info, desc, etc).
 
2e cas : On met directement le id_version dans la table 'users' c'est à dire 'users' (id_user, fname, lname, id_version) et on supprime la table de liaison 'user_version'.
 
 
Sachant qu'il y aura un nombre très important de requêtes et qu'on aimerait pas trop taper souvent (ou même juste une fois par utilisateur) dans la table 'users', est-ce plus intéressant niveau performances d'avoir l'id_version dans la table 'users' ou d'avoir une table de liaison avec un index plus fort. Le fait de taper dans 2 tables mais d'avoir un index plus fort, est-ce que ça revient au même/plus rapide/plus lent ?
 
 
J'ai essayé d'être le plus clair possible Merci d'avance
 

Je suis pas sûr d'avoir suivi, là. Si tu n'as qu'une version par user, pourquoi une nouvelle table?

Pour éviter d'avoir 2 index dans la table 'users', on me dit que de faire une table de liaison ('user_version') avec un index sur l'id_version c'est plus "propre" et aussi bien niveau performances.
 
Et moi je dis que non puisque l'on doit faire un select (imbriqué) dans les 2 tables ('users' et 'user_version').
 
Ça a un intérêt pour moi d'avoir la réponse dans le sens où il y a aura des milliers de requêtes dans ces tables dans un laps de temps assez court.

Je vois pas en quoi c'est plus propre de créer une table qui ne sert à rien...

100%++ avec skeye...
 
l'unique intérêt d'avoir une table de correspondance, c'est si plusieurs version_id se rattachent à un même user_id et vice-versa.
 
dans tous les cas, avoir cette troisème table sera plus lent que d'avoir seulement deux tables. donc elle n'est à créer que si elle est nécessaire...