10

個人的なプロジェクトとしてプロジェクト管理システムのデータベース設計に取り組んでいますが、問題が発生しました。

チケットシステムを実装したいのですが、チケットを Tracのチケットのように見せたいと思っています。このシステムを複製するには、どの構造を使用しますか? (どのシステムにも trac のインストールに成功したことがないので、実際に何をしているのかわかりません)

注：どのバージョンでもチケットを保存または表示しようとすることに興味はありません。変更履歴だけが必要です。余分なデータを保存したくありません。また、テキスト フィールドでシリアル化された配列を使用して、このような機能を実装しました。私はそれを解決策として二度と実装したくありません。

編集: データベース構造のみを探しています。トリガー/コールバックは実際には問題ではありません。

4

6 に答える 6

18

「薄い」設計を使用して、純粋なレコード変更データを実装しました。

RecordID  Table  Column  OldValue  NewValue
--------  -----  ------  --------  --------

デザインによっては、「テーブル」や「列」ではなく、「オブジェクト」や「プロパティ」などを使用したい場合があります。

これには、柔軟性と単純さという利点がありますが、クエリの速度は犠牲になります。「テーブル」列と「列」列のクラスター化インデックスは、クエリとフィルターを高速化できます。ただし、テーブルまたはオブジェクト レベルで変更ログをオンラインで頻繁に表示する場合は、よりフラットなものを設計することをお勧めします。

EDIT : 何人かの人々が、このソリューションでは変更セットをまとめることができないと正しく指摘しています。上の表でこれを忘れていました。私が使用した実装には、日時、ユーザー、その他の情報を含む「Transaction」テーブルと、「TransactionID」列もあったため、設計は次のようになります。

CHANGE LOG TABLE:
RecordID  Table  Column  OldValue  NewValue  TransactionID
--------  -----  ------  --------  --------  -------------

TRANSACTION LOG TABLE:
TransactionID  UserID  TransactionDate
-------------  ------  ---------------
于 2008-09-26T20:09:16.877 に答える
3

私はこのようなことをしました。ID (PK) を含む LoggableEntity というテーブルがあります。

次に、loggableentity (レコード) に対して行われた変更に関する情報を含む EntityLog テーブルがあります: ID (PK)、EntityID (LoggableEntity.ID への FK)、ChangedBy (変更を行ったユーザー名)、ChangedAt (変更が発生したときの smalldatetime)、タイプ (列挙型: 作成、削除、更新)、詳細 (変更内容を含むメモ フィールド - シリアル化された詳細を含む XML の可能性があります)。

追跡したいすべてのテーブル (エンティティ) は、LoggableEntity テーブルから「派生」しています。たとえば、顧客が LoggableEntity テーブルへの FK を持っていることを意味します。

これで、私の DAL コードは、顧客レコードに変更が加えられるたびに EntityLog テーブルの作成を処理します。エンティティ クラスがログ可能エンティティであることがわかるたびに、新しい変更レコードがエンティティ ログ テーブルに追加されます。

だからここに私のテーブル構造があります：

+------------------+           +------------------+
| LoggableEntity   |           | EntityLog        |
| ---------------- |           | ---------------- |
| (PK) ID          | <--+      | (PK) ID          |
+------------------+    +----- | (FK) LoggableID  |
        ^                      |      ...         |
        |                      +------------------+
+------------------+
| Customer         |
| ---------------- |
| (PK) ID          |
| (FK) LoggableID  |
|      ...         |
+------------------+
于 2008-09-26T20:35:58.557 に答える
3

このようなデータベースメカニズムを求めていますか?

   CREATE OR REPLACE TRIGGER history$yourTable
        BEFORE UPDATE ON yourTable
        FOR EACH ROW
        BEGIN
            INSERT INTO
                history
            VALUES
                (
                :old.field1,
                :old.field2,
                :old.field3,
                :old.field4,
                :old.field5,
                :old.field6
                );
        END;
    /
    SHOW ERRORS TRIGGER history$yourTable
于 2008-09-26T20:05:22.610 に答える
2

余分なデータをたくさん保存しない限り、それを行うための良い方法は考えられません。変更を確認するには、すべてのリビジョンを保存する必要があります。

これが私が見た解決策の1つですが、それが最良の解決策であるかどうかはわかりません。id特定のリビジョンを指す主キーを用意します。ticket_numberとフィールドもありrevision_dateます。ticket_numberチケットを修正しても変更されませんが、変更されidますrevision_date。次に、コンテキストに応じて、 groupwise maxを使用して、特定のリビジョンまたは特定のチケットの最新のリビジョンを取得できます。

于 2008-09-26T20:11:11.317 に答える
1

システム内で何かが発生するたびにpingを実行し、イベントの説明をデータベースに配置する、ある種のイベントリスニングクラスを作成すると思います。

基本的な誰が/何を/どこで/いつ/何の情報を保存する必要があります。

その project-events テーブルを並べ替えると、必要な情報が得られるはずです。

于 2008-09-26T20:03:22.023 に答える
0

考えられる解決策の 1 つは、変更を行ったユーザーの履歴テーブルにチケットのコピーを保存することです。

ただし、これには大量の余分なデータが保存され、Trac が表示するビューを作成するために大量の処理が必要になります。

于 2008-09-26T20:09:47.827 に答える