Il semble que vous connaissiez déjà la réponse, mais rappelez-vous, gardez les systèmes que vous concevez simples à modifier car les modèles commerciaux changent toujours avec le temps ou ils finissent par échouer (c'est une généralisation mais vous voyez l'idée). Un corollaire de cela est que si vous faites un modèle rigide, rapide ou lent, c'est rigide, les changements seront plus difficiles et l'utilisateur final ne verra pas la différence, donc aucun changement d'argent/bonheur n'est réalisé, à moins que ce ne soit un très mauvais changement. Votre problème n'est pas technique dans le sens où une requête fonctionne sur le moteur, mais plutôt philosophique, changements faciles par rapport à la vitesse apparente. Demandez-vous quel est l'avantage d'avoir une base de données normalisée ? Pensez à une architecture et à un design propres, les performances sont le moindre problème dans le monde d'aujourd'hui car le traitement est moins cher et le stockage également. Mais la conception coûte cher. La normalisation a été faite pour créer des systèmes qui ne dépendent pas de décisions de dernière minute mais d'un processus de conception structuré. Il ne s'agit pas seulement d'ajouter une colonne de plus, il s'agit de la structure rigide des données elles-mêmes. Finalement, avec le temps, vous ajouterez simplement des colonnes contenant des index, et ces index pointeront vers de petites tables. MySql va de toute façon contourner toutes ces données. Je vais donc opter pour la première, beaucoup de petites tables, plusieurs à plusieurs.
