わかりました。あなたのダイアレンマがわかりました。データベースの専門家が（おそらく短命で）不在の場合は、私の意見を述べます。
正気のためにあなたのデータを分割します。人に関する情報を保存しているとしましょう。 1つのテーブルに200列は必要ありません。それらを分割し、多くのテーブルに複数の列を含める必要があります。例：
tblGeneralCharacteristics:
- colEyeColor
- colHairColor
- colHeight
- colWeight
tblInterests:
- colFaveColor
- colFaveSport
tblRelationships
- colMother
- colFather
- colBrother
- colSister
この方法ははるかに優れています。計算上、それが重要だとは思えません。明らかに、クエリごとに返されるデータが少なくなるため、一部のレポート（すべてのデータを取得したり、すべてのデータをトロールしたりする必要がない場合）では、より高速になる可能性があります（ただし、データベースに適切にインデックスを付けると、問題にはなりません。
次号へ。データベース内のレコード数のそれ。 10,000が少し大きくなり始めたら、キャッシュを開始します。
さて、私に関する限り、データをキャッシュする正しい方法も間違った方法もありません。必要なのは必要なものです。たとえば、あなたの質問では、2012年1月から3月の間に入力されたレコードの平均身長を取得することに言及しました。そうですね...その月に入力されたすべてのレコードの体重の平均身長を計算してこれを保存するcronスクリプトを作成できます。どこかの別のテーブルに。次に、レポートを作成するときに、1月、2月、3月の値を取得し、それらを平均化するだけで済みます...これははるかに簡単です。潜在的に数千行に対して計算クエリを実行する代わりに、数百行に対してcronクエリ（時間は関係ありません）を実行し、実際のレポートは3行のみをクエリします。
>もう1つのトリックは、SQLで実行できる計算が多ければ多いほどよいということです。フィールド/レコードを平均化する場合、または何かを合計する場合は、SQLクエリで送信します。 SQLサーバーは、ふるいにかけるために大量のデータを返すのではなく、計算を実行して結果を返します。これは必ずしも簡単で便利なわけではありませんが、SQLをより効果的に使用できるようになるほどです。
お役に立てれば。私が言ったように、データベースの専門家はあなたにもっと洞察に満ちたアドバイスを与えることを望んでいると確信しています。 :)