Ik weet meer over mssql dan mysql, maar ik denk niet dat het aantal joins of het aantal rijen waar je het over hebt, je teveel problemen zou moeten geven met de juiste indexen. Heb je het zoekplan geanalyseerd om te zien of je er een mist?
http://dev.mysql.com/doc/refman/5.0 /en/explain.html
Dat gezegd hebbende, als je eenmaal tevreden bent met je indexen en alle andere wegen hebt uitgeput, is de-normalisatie misschien het juiste antwoord. Als je slechts een of twee vragen hebt die problemen opleveren, is een handmatige aanpak waarschijnlijk geschikt, terwijl een soort datawarehousing-tool misschien beter is om een platform te creëren om datakubussen te ontwikkelen.
Hier is een site die ik heb gevonden en raakt aan het onderwerp:
http://www.meansandends.com /mysql-data-warehouse/?link_body%2Fbody=%7Bincl%3AAggregation%7D
Hier is een eenvoudige techniek die u kunt gebruiken om het denormaliseren van query's eenvoudig te houden, als u er maar een paar tegelijk doet (en ik vervang uw OLTP-tabellen niet, maar maak gewoon een nieuwe voor rapportagedoeleinden). Stel dat u deze vraag in uw toepassing heeft:
select a.name, b.address from tbla a
join tblb b on b.fk_a_id = a.id where a.id=1
Je zou een gedenormaliseerde tabel kunnen maken en deze met bijna dezelfde query vullen:
create table tbl_ab (a_id, a_name, b_address);
-- (types elided)
Merk op dat de onderstrepingstekens overeenkomen met de tabelaliassen die u gebruikt
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
Om vervolgens uw app te corrigeren om de nieuwe gedenormaliseerde tabel te gebruiken, verwisselt u de punten voor onderstrepingstekens.
select a_name as name, b_address as address
from tbl_ab where a_id = 1;
Voor grote zoekopdrachten kan dit veel tijd besparen en maakt het duidelijk waar de gegevens vandaan komen, en kun je de vragen die je al hebt hergebruiken.
Onthoud dat ik dit alleen als laatste redmiddel bepleit. Ik wed dat er een paar indexen zijn die je kunnen helpen. En als u de-normaliseert, vergeet dan niet om rekening te houden met de extra ruimte op uw schijven en bedenk wanneer u de query uitvoert om de nieuwe tabellen te vullen. Dit zou waarschijnlijk 's nachts moeten zijn, of wanneer de activiteit laag is. En de gegevens in die tabel zullen natuurlijk nooit helemaal up-to-date zijn.
[Nog een bewerking] Vergeet niet dat de nieuwe tabellen die je maakt ook geïndexeerd moeten worden! Het goede is dat u naar hartelust kunt indexeren en u zich geen zorgen hoeft te maken over de strijd met de updatevergrendeling, aangezien de tabel naast uw bulkinvoeging alleen selecties ziet.