0


0

私の場合はあなたの意見を聞きたい。 大きなテーブルがあります。 そして毎月、私たちはそのテーブルについて報告します。 つまり、最大20000レコードをPDFまたはExcelファイルとしてダウンロードして印刷する必要があります。 私はリアルタイムでレポートを生成することを計画しています。 事前生成なし。 それは私の問題を解決するための良い方法ですか? またはもっと良いアイデアがあれば、それを聞きたいです。

ありがとう

4 Answer


2


私はあなたの質問を完全には受けていません。しかし、本当に大きなテーブルまたは複数の本当に大きなテーブルについてリアルタイムのレポートを作成する必要がある場合は、必要な合計を事前に計算します。

それで、以下のような問い合わせの代わりに:

count()、sum(items) price、datefield、bigtableからのタイプbt join本当に素晴らしいrbt on bt.id = rbt.rbtidここでdateフィールドは '2009年1月1日’から '2009年1月31日’の間でタイプ別にグループ化されます。デートフィールド

ストアドプロシージャで1日の合計を毎晩2番目のテーブルに計算するようにします。それから、結合を数えてba-zillionレコードを合計するのではなく、30日分の計算済みの合計を単純に加算します。


1


このPDFを大量に生成しようとしているかどうかによって異なります。 これを頻繁に生成している場合は、この「大きなテーブル」を常に処理しないように、最後に生成されたPDFを15〜30分間キャッシュすることをお勧めします。

すべてのデータを取得するには少し時間がかかりますが、遅延を気にしないのであれば、事前に生成しないことをお勧めします。

たくさんの人がPDFにアクセスしていて、遅延を避けたく、データがそれほど急激に変化しないのであれば、おそらく事前に生成しておくべきです。 生成間隔は、データがどれだけ早く古くなるかと一致している必要があります。 データが1日に1回変更される可能性がある場合は、毎日の更新で通常は十分です。 データが大きく変わる場合は、30分ごとに生成される可能性があります。

ですから、だれがPDFにアクセスするのか、またどのくらいの頻度でアクセスするのかによって異なります。


1


それほど大きなレポートを作成しているのであれば、ユーザーが頻繁に更新を期待することを想像するのは困難です。 一般的に言って、私は人々が一貫して繰り返し可能なビューをせいぜい毎日ダウンロードできることにかなり高い価値を置いていると考えています。 実際、その一貫性/再現性は通常、レポートを1日に1回以上リフレッシュしてから結果を保存する良い理由です。

特定のレポートが毎日必要とされることがほとんどない場合は、特定の日に作成された最初のコピーを保存して遅延レポートを生成し、 "RepABC_05032009.xls"のようなファイル命名規則を使用することができます。特定の日のレポートのマーカーとして。


0


20000レコードはそれほど大きくないので、「オンザフライ」で生成しても確実にうまくいきます(それらのレコードを取得するためのクエリが複雑で遅い場合を除く)。

実装がはるかに簡単なので、Excelを使用することをお勧めします。 csvデータを出力するだけで(PHPには既製の関数があります)、それに応じて適切なコンテンツヘッダを送信してください。

PDFではなくExcelを使用するもう1つの理由は、印刷前にユーザーが若干の微調整や修正を行うことができることです(横長/縦長レイアウト、行番号の変更、カスタムメモの追加など)。