[FN]Choix dans la conception

Bonjour à tous,

Je planche actuellement sur la conception de la bdd d'un futur site web a (très) fort traffic et je suis face à une question.
Dois je privilégier une structure "comme-on-dis-a-l-ecole" c'est à dire avec des forme normales les plus aboutis ou puis je penser "performance serveur" pendant ma conception ?

Je m'explique,

J'ai une base "jeux" dans la quelle j'ai ces champs :

id + nom + id_categorie

Puis une base "catégorie" qui se compose comme suit :

id + libelle

Sachant que un jeux peut avoir plusieurs catégories dois je opter pour une table qui fait la liaison entre les deux précédentes (donc au mnimum autant d'enregistrement que de jeux et une requete plus conséquente) ou alors dois je préféré un champs id_catégorie multivalué que je traite via php par la suite ?

Sachant que nous utilisons mysql quel est le meilleur choix pour ne pas mettre le serveur à genoux lorsque quelques centaines de visiteurs seront connectés

Sans hésitation, une table de liens. Non seulement c'est plus "académique", mais surtout ce sera nettement plus performant ! De plus, faire des champs multivalués rendrait à peu près impossible l'exécution d'une requête comme "Trouver tous les jeux de la catégorie Tartanpion", ou alors mettrait ton PC à genoux.

Sache que faire une jointure est certe "coûteux", mais tout bon SGBDR possède de nombreuses façons d'optimiser cette opération (jointures tardives, index, ...). Fais-lui confiance pour faire la jointure de façon performante, c'est son boulot et il est impensable que du code php fait maison (ou pas fait maison d'ailleurs) batte les quelques 10 ans (au moins) d'historique de développement de ton SGBDR.
Il est en général une très mauvaise idée de partir du principe que tu feras mieux que ta base de données et de faire les traitements / filtrage dans ton application. Procéder ainsi est une source de très grosses pertes de performances.

Je te conseille vraiment de partir d'un schéma bien normalisé (ou presque) et de dénormaliser au cas par cas en fonction des besoins (avec des colonnes précalculées par des triggers par exemple).