レポート用にオカレンスを保存する

data-structures database database-design postgresql
レポート用にオカレンスを保存する

イベントの発生をデータベースに保存して、レポートをすばやく取得するための最良の方法は何ですか? すなわち(総出現数、日付範囲間の出現数)。

現在、2つのデータベーステーブルがあります。1つはイベントの個々のタイムスタンプをすべて保持します-日付範囲でクエリを実行でき、1つは集計のためにその数をすばやく取得できるように合計数を保持します

表1:

Event | Total_Count
------+------------
bar   |  1
foo   |  3

表2

Event | Timestamp
------+----------
bar   | 1/1/2010
foo   | 1/1/2010
foo   | 1/2/2010
foo   | 1/2/2010

この問題へのより良いアプローチはありますか? 私は日付範囲のクエリがタイムスタンプではなく日付全体でのみ実行されるため、日付集計を保持するために表2を変換することを考えています、それはより効率的であるはずです(1/1/2010 vs 1/1/2010 00 :01:12)すなわち:

表2を更新

Event |   Date   | Total_Count
------+----------+------------
bar   | 1/1/2010 |  1
foo   | 1/1/2010 |  1
foo   | 1/2/2010 |  2

おそらく、この問題に取り組むためのさらに賢い方法がありますか? 何か案は?

  0  0


ベストアンサー

イベントのタイムスタンプを持つテーブルが1つだけあります。 次に、レポートは単に「where」句を正しく設定するだけです…​

または、あなたの質問に何か欠けていますか?

1


あなたのアプローチは良いようです。 表2は詳細表として、表1はサマリー表として見ています。 ほとんどの場合、表2のみに挿入を行い、表1に対して挿入と更新を行います。

更新された表2には、追加の利点はありません。 ただし、日単位の集計が最も重要な場合は検討する必要があります。

テーブルにさらに属性(列)を追加することを検討できます。 たとえば、表1にfirst_dateとlast dateを追加できます。

1


本当に要件はないようです:

タイムスタンプから日付部分だけに変更することは大したことです。 時刻分析を行いたくないですか? メンテナンスが「foo」の発生を止めた場合、メンテナンスを行うのに最適な時間は何ですか。

そして、あなたはサイズを心配していませんか? あなたは何百万ものレコードを持っていると言います(それはたくさんのように)、そしてあなたは余分な列によってすべての単一の行を拡張します。 行数が急増するまで、1つの列は多くありません。そして、各列について本当に考える必要があります。

したがって、過去3日間のイベントの合計を取得するには、これを行います。

SELECT SUM(totcnt) FROM (
SELECT MAX(Total_count) as totcnt from table where date = today and event = 'Foo'
UNION ALL
SELECT MAX(Total_count) from table where date = today-1 and event = 'Foo'
UNION ALL
SELECT MAX(Total_count) from table where date = today-2 and event = 'Foo'
)

ええ、それはより簡単に見える>

SELECT COUNT(*) FROM table WHERE DATE BETWEEN today-2 and today and event = 'foo'

そして、行を追加するために必要なトリガーについて考えてください…​ その日とイベントの最大値を取得し、追加します…​ 挿入するたびに?

使用しているサーバーの種類はわかりませんが、285msで100万行を合計しました。 そう…​ あなたは何百万人を持ち、それらを合計するのに何回必要であり、同じ日付範囲のすべての時間または完全にランダムですか?

1


タイトルとURLをコピーしました