2

私たちが提供するサービスを詳述するための「サービス」テーブルがあります。記録が必要なデータの中には、次のようないくつかの小さな 1 対多の関係があります (すべて、service_id への外部キー制約があります)。

service_owners -- user_ids responsible for delivery of service
service_tags -- e.g. IT, Records Management, Finance
customer_categories -- ENUM value
provider_categories -- ENUM value
software_used -- self-explanatory

私が抱えている問題は、元の列に一致する履歴テーブルへの挿入を実行するテーブルで更新トリガーを使用しているサービスの更新履歴を保持したいということです。ただし、上記のデータに対して正規化されたアプローチが使用され、1 対多の関係ごとに個別のテーブルと外部キーが使用される場合、これらのテーブルの更新はサービスの履歴で認識されません。

誰か提案はありますか？サービス履歴の整合性を維持するために、サービス テーブルに子キーを格納する必要があるようです。区切られたテキストフィールドはここで有効なアプローチですか、それともpostgreSQLを使用しているので、おそらく配列も有効なオプションですか? しかし、これらはやや汚れているように感じます！

ありがとう。

4

2 に答える 2

2

テーブルが次の場合:

create table T (
    ix int identity primary key,
    val nvarchar(50)
)

そして、あなたの履歴テーブルは次のとおりです。

create table THistory (
    ix int identity primary key,
    val nvarchar(50),
    updateType char(1), -- C=Create, U=Update or D=Delete
    updateTime datetime,
    updateUsername sysname
)

次に、関心のあるすべてのテーブルに更新トリガーを配置するだけです。その後、履歴の任意の時点での任意またはすべてのテーブルの状態を調べて、その時点での関係を判断できます。

于 2012-06-26T14:27:35.347 に答える
1

可能な限り、データベースで配列を使用することは避けたいと思います。

あなたがここで言っている正確な理由のために私は更新が好きではありません...それが上書きされるのであなたは情報を失います。私の答えは非常に単純です...更新しないでください。これを実装できる時点かどうかはわかりませんが、可能であれば、メインテーブル自体を使用して履歴を保存することをお勧めします（2番目の履歴テーブルのセットは必要ありません）。

'active'という列をメインヘッダーテーブルに追加します。これは、文字またはビットにすることができます（0はオフ、1はオン）。次に、それはちょっとしたトリガーの魔法です...更新が実行されると、ステータスが「0」（または非アクティブ）で上書きされているレコードと同じ行をテーブルに挿入してから、既存の行を更新します（これはプロセスはアクティブなレコードのID列を同じに保ちます。新しく挿入されたレコードは、新しいIDを持つ非アクティブなレコードです）。

このようにして、データが失われることはなく（確かに、かなりの数の行を格納しています...）、active=0の選択で履歴を簡単に表示できます。

ここでの問題は、すでに実装されているものに取り組んでいる場合です...このテーブルにヒットする既存のクエリはすべて、アクティブな列のチェックを含めるように更新する必要があります。新しいシステムを設計している場合、このソリューションの実装は非常に簡単になりますが、長年のアプリケーションの場合は面倒です。残念ながら、where句を変更できるようになるまで、既存のレポートにはオフレコードとオンレコードの両方が（エラーをスローせずに）含まれます。

于 2012-06-26T18:26:03.907 に答える