J'en sais plus sur mssql que mysql, mais je ne pense pas que le nombre de jointures ou le nombre de lignes dont vous parlez devrait vous causer trop de problèmes avec les index corrects en place. Avez-vous analysé le plan de requête pour voir s'il vous en manque ?
http://dev.mysql.com/doc/refman/5.0 /fr/explain.html
Cela étant dit, une fois que vous êtes satisfait de vos index et que vous avez épuisé toutes les autres voies, la dénormalisation pourrait être la bonne réponse. Si vous avez juste une ou deux requêtes qui posent problème, une approche manuelle est probablement appropriée, alors qu'une sorte d'outil d'entreposage de données pourrait être préférable pour créer une plate-forme pour développer des cubes de données.
Voici un site que j'ai trouvé qui aborde le sujet :
http://www.meansandends.com /mysql-data-warehouse/?link_body%2Fbody=%7Bincl%3AAgregation%7D
Voici une technique simple que vous pouvez utiliser pour simplifier la dénormalisation des requêtes, si vous n'en faites que quelques-unes à la fois (et je ne remplace pas vos tables OLTP, j'en crée simplement une nouvelle à des fins de création de rapports). Supposons que vous ayez cette requête dans votre application :
select a.name, b.address from tbla a
join tblb b on b.fk_a_id = a.id where a.id=1
Vous pouvez créer une table dénormalisée et la remplir avec presque la même requête :
create table tbl_ab (a_id, a_name, b_address);
-- (types elided)
Notez que les traits de soulignement correspondent aux alias de table que vous utilisez
insert tbl_ab select a.id, a.name, b.address from tbla a
join tblb b on b.fk_a_id = a.id
-- no where clause because you want everything
Ensuite, pour que votre application utilise la nouvelle table dénormalisée, remplacez les points par des traits de soulignement.
select a_name as name, b_address as address
from tbl_ab where a_id = 1;
Pour les requêtes volumineuses, cela peut faire gagner beaucoup de temps et indiquer clairement d'où proviennent les données, et vous pouvez réutiliser les requêtes que vous avez déjà.
Rappelez-vous, je ne préconise cela qu'en dernier recours. Je parie qu'il y a quelques index qui pourraient vous aider. Et lorsque vous dénormalisez, n'oubliez pas de tenir compte de l'espace supplémentaire sur vos disques et de déterminer quand vous exécuterez la requête pour remplir les nouvelles tables. Cela devrait probablement être la nuit ou lorsque l'activité est faible. Et les données de ce tableau, bien sûr, ne seront jamais exactement à jour.
[Encore une autre édition] N'oubliez pas que les nouvelles tables que vous créez doivent également être indexées ! La bonne partie est que vous pouvez indexer le contenu de votre cœur et ne pas vous soucier des conflits de verrouillage de mise à jour, car en dehors de votre insertion en masse, le tableau ne verra que les sélections.
