私のアプリケーションは一種の POS システムです。問題はレポートにあります。製品ごと、テーブルごと、スタッフごと、カテゴリごとの売上。1 年間の日付範囲レポートは、多数の行などを合計する必要があるため、非常に遅くなります。したがって、1 日あたりの集計など、SQL を使用しないデータベースが役立つかどうか疑問に思っています。各項目・商品・カテゴリ・スタッフなどの問合せを受け付けております。だから私は何ができますか？
質問する
337 次
1 に答える
5
リレーショナルデータベースに慣れている場合は、リレーショナルデータベースを使い続け、一般的に使用するレポートに日次集計テーブルを使用することをお勧めします。
たとえば、製品番号ごとにグループ化された販売レポートを作成する場合は、探している統計（つまり、販売数量）を把握し、生データを製品番号ごとに1日サイズの「バケット」に集約します。
+-----------+------------+------------+-------+-------+
| salesdate | productNum | totalSales | stat2 | stat3 |
+-----------+------------+------------+-------+-------+
毎日の終わりに1日サイズのバケットを実行する場合、レポートには1か月あたり30バケット、または1年あたり365バケットしかありません。要約するのがはるかに速くなります。ダッシュボード（時間サイズのバケット）を構築するときにネットワークパフォーマンスメトリックを使用してこれを実行しました。これにより、クエリ時間が大幅に短縮されます。必要に応じていつでも生データを掘り下げることができますが、何かを一目で確認したい平均的なユーザーにとっては、集約されたバケットで十分です。
サマリーテーブルを別のデータベースに配置することも検討してください。
統計の1つが平均である場合、一連の平均の平均は範囲全体の平均ではないことに注意してください。
于 2012-08-19T13:08:47.857 に答える