Ok, jag ser ditt dialemmat, och i (förmodligen kortlivad) frånvaro av en databasexpert kommer jag att ge dig min åsikt.
För förnuftets skull bryt upp dina data. Låt säga att du lagrar information om personer. Du behöver inte 200 kolumner i en tabell. Du bör dela upp dem och ha flera kolumner i många tabeller. t.ex.
tblGeneralCharacteristics:
- colEyeColor
- colHairColor
- colHeight
- colWeight
tblInterests:
- colFaveColor
- colFaveSport
tblRelationships
- colMother
- colFather
- colBrother
- colSister
Det här sättet är mycket bättre. Beräkningsmässigt tvivlar jag på att det spelar någon roll. Uppenbarligen får du mindre data tillbaka för varje fråga, så för vissa rapporter (där du kanske inte behöver hämta all data eller trawla igenom all data) kan det gå snabbare (även om du indexerar databasen ordentligt så borde det inte vara ett problem).
Till nästa nummer. Det av mängden poster i databasen. Om 10 000 börjar bli lite stort är det dags att börja cache.
Nu, för mig, finns det inget rätt eller fel sätt att cache data. Vad du behöver är vad du behöver. Så till exempel, i din fråga nämnde du att få genomsnittliga höjder för vikt för inmatade poster mellan jan och mars 2012. Tja... du kan skriva ett cron-skript som beräknar medelhöjderna för vikt för alla inmatade poster den månaden och lagrar detta i en annan tabell någonstans. När du sedan kommer för att skapa din rapport behöver du bara få värdena för jan, feb och mars och avg dem... det är mycket enklare. Istället för att göra en beräkningsfråga på potentiellt tusentals rader, gör du en cron-fråga (vilket inte spelar någon roll hur lång tid det tar) på ett par hundra rader, och sedan frågar själva rapporten bara 3 rader.
Ett annat knep är att ju fler beräkningar du kan göra i SQL desto bättre. Om du vill snitta fält/poster, eller lägga ihop något så skicka det med din SQL-fråga. SQL-servern kommer att göra beräkningen och returnera resultatet, snarare än att returnera dig enorma mängder data att sålla igenom. Jag vet att detta inte alltid är lätt/användbart, men ju mer du kan få SQL att göra desto bättre.
Hoppas det här hjälper. Som jag sa, jag är säker på att en databasexpert längtar efter att ge dig några mer insiktsfulla råd. :)