1

アイテムがキューからキューへと絶えず移動するときに、時間の経過に伴うキューの大きさ (レコード数) をクエリできるようにする SQL データ構造を設計するにはどうすればよいでしょうか (グラフ化できるようにするため)。

テーブル:

Queue
--------------------------------------
item_id      int
status       enum('new','ready','old')

Log
--------------------------------------
item_id      int
old_status   enum('new','ready','old')  --perhaps record new_status instead?--
change_date  timestamp

アイテムのステータスが変わるたびに (つまり、新しいキュー)、ログに記録します。

「10:00 に X レコードが 'new' にあり、Y が 'ready' にあるなど」というクエリを作成するにはどうすればよいですか。そして、グラフ化できるように、これを 1 日を通して行います。

事前にタイミングの粒度がわからないため、5 分ごとの合計でテーブルを作成したくありません。

データベース構造を変更し、新しいフィールドを追加して、これを機能させることはまったく問題ありません。

4

2 に答える 2

1

ログに新しいステータスと古いステータスの両方が記録されている場合、各ステータスのインクリメントおよびデクリメント カウンタとして機能する新しい疑似列をテーブルに追加できます。

SELECT 
    l.change_date
    CASE WHEN l.new_status = 'new'   THEN 1 WHEN l.old_status = 'new'   THEN -1 ELSE 0 END AS new_count
    CASE WHEN l.new_status = 'ready' THEN 1 WHEN l.old_status = 'ready' THEN -1 ELSE 0 END AS ready_count
    CASE WHEN l.new_status = 'old'   THEN 1 WHEN l.old_status = 'old'   THEN -1 ELSE 0 END AS old_count
  FROM log l
  ORDER BY l.change_date

特定の日付までの疑似列を合計すると、その日付にアクティブだったものの数が残ります。分析的な SUM 関数は適切なツールのように思えます。これは、古い状態と新しい状態が決して同じではないことを前提としています。たぶん、あなたはそのようなものを適用することができます。

于 2013-06-06T02:22:08.647 に答える
1

テーブルのクエリlogにコストがかかると思われる場合は、スナップショット テーブルを作成できます。これにより、たとえば毎日、各キュー内のレコード数がキャプチャされます。毎日の終わりに、このテーブルに新しい行を挿入します。そのため、いつでも数値を確認するには、その日のこの時間の変更を、前日の終わりに取得したスナップショットに適用するだけです。change_dateテーブルの列にインデックスを付けるlogと、このクエリはかなり高速に実行されると思います。

于 2013-06-06T20:20:27.920 に答える