0

午後。

最近、イベントベースのサポートチケットシステムの開発を任されましたが、多くの問題が発生しており、問題はデータベースの構造にあると思います。

現時点では、次のようになっています。

create table tickets (
    ticket_id int not null primary key auto_increment,
    stage_id int not null default 0,
    name varchar(255) not null default ''
    /* etc... */
);
create table ticket_events (
    event_id int not null primary key auto_increment,
    ticket_id int not null,
    date datetime,
    stage_id
);
create table stages (
    stage_id int not null primary key auto_increment,
    name varchar(255)
);

したがって、チケットがステージを変更するたびに、チケットが移動したステージとタイミングを指定する新しい行がticket_eventsテーブルに追加され、チケットテーブルのstage_idフィールドが新しいステージで更新されます。

問題は、チケットの現在のステージがtickets.stage_idとticket_eventsテーブルの最新のレコードの両方で定義されているため、これがデータベースの正規化ルールに違反することです。ある時点での未処理のチケットの数を示すレポートを作成しようとしたところ、なぜこのようになっているのかがわかりました。イベントテーブルから現在のステージをすばやく取得するために、どのような種類のSQLも取得するのは非常に難しいようです。

この非常に役立つページ（http://kristiannielsen.livejournal.com/6745.html）でオプション2を使用して適度に高速なクエリを作成できましたが、問題が発生して行き詰まりました。

現在のデータでは、event_idは常に日付に対して昇順で実行されるとは限りません。さらに、特定の自動処理スクリプトにより、1つのチケットにまったく同じ日付の2つのイベントが含まれる可能性があります。つまり、イベントテーブルを使用しようとするクエリは、「日付順、event_id」である必要があります。これは、サブクエリやグループ化ではほとんど不可能です。

これらの問題を克服するために私がどのように取り組むことができるかについて誰かがアドバイスを与えることができますか？イベントの順序を定義するより良い方法はありますか？

どうもありがとう。サイモン

4

3 に答える 3

0

正規化ルールはガイドラインです。それらは多くの状況に適用されますが、すべてではありません。ルールに「違反する」ことは自動的に悪いことではありませんが、すべての状況でルールに奴隷に従うことは間違いなく悪いことです.

それらは道路のルールと同じであると考えてください - 常に制限速度に従う、道路の側にとどまるなど..彼の車とあなたの車を合流させます。

于 2011-07-18T15:46:45.470 に答える
0

ticket.stage_id を ticket_events テーブル (last_event) への FK に置き換え、新しいイベントが挿入されるたびにトリガーが ticket.last_event フィールドをイベントの PK に更新します。これにより、イベントテーブルから現在のステージを見つけるための簡単/迅速な参加が可能になります。

于 2011-07-18T15:52:44.180 に答える
0

もう 1 つの方法は、チケット テーブルに「次のイベント ID」を設定することです。イベントを作成するときは、それを使用してから更新します。その後、独自の独立した順序を設定できます。または、日付/時刻が同じ場合の二次的な順序として機能する「優先度」フィールドを使用することもできます。

正確な要件についてもう少し考える必要があるようです。

于 2011-07-18T15:49:05.643 に答える