1

andがItemありTag、それぞれにidandname列のみItem_Tag_Mapがあり、複合Item.id, Tag.id主キーを持つテーブルがあるとします。

Itemandの履歴テーブルを実装したい場合Tag、これは比較的簡単に思えます -主キーとして and ("INSERT","UPDATE",etc)を使用してorテーブルrevisionにコピーするための 3 番目の列とトリガーを追加できます。アイテムを「削除」したい場合があるため、次の 2 つの方法のいずれかを実行できます。ItemHistoryTagHistoryid, revisionoperation

  • ItemまたはTagに別の列を追加しis_active、実際に行を削除しないでください。
  • 行を削除しますが、delete操作として履歴テーブルに削除を記録し、Itemまたは挿入時に、そのアイテムを含むまたはテーブルからTag最新のrevision番号を取得し、そのように設定しますItemHistoryTagHistory

2番目のオプションは口に悪い味が残るので、最初のオプションを使用しても問題ありません. 結局のところ、アイテムを変更したり、アクティブなステータスを変更したりできるのに、なぜ本当にアイテムを削除する必要があるのでしょうか?

ここで、テーブルの履歴テーブルで同じ問題に遭遇しましたItem_Tag_Mapが、今回はどちらのオプションもそれほど魅力的ではないようです。is_activeに を追加することを選択した場合Item_Tag_Map、タグがアイテムにマップされているかどうかを調べるロジックは次のように変わります。

これらのアイテムのすべての tag_mapping を取得します

に

これらのアイテムのすべての tag_mapping を取得する WHERE is_active

マッピングの存在はマッピングが存在することを意味するという暗黙の考えはなくなります。マッピングされていないアイテム タグのセットには、テーブルに存在しないすべてのタグだけでなく、is_activefalse のタグも含まれます。

一方、2 番目のオプションを選択した場合、それはまだかなり醜いです。

これまでに何度もこの問題に遭遇したことがあると思います。あなたがどのように対処したかを知りたいです。

4

1 に答える 1

2

私の答えはいくつかのことに依存するので、私の仮定を述べようと思います。

アイテムとタグのis_activeは大丈夫だと思います。これら 2 つのエンティティでレコード サイズが急速に大きくなる場合は、夜間ジョブを実行して、非アクティブなレコードをテーブルのアーカイブ バージョンに移動することを検討してください。これは、後でレポートや監査に使用できます。必要に応じてレコードを復元するスクリプトを作成することもできますが、リアルタイム テーブルは高速であり、データが削除されていないという考えがあります。

ユーザーがマッピングを追加/更新/削除できるようにすると、テーブルはアイテムとタグと同じと見なされます。フラグを追加して、クエリで使用します。私には醜いようには見えません - 以前に見たことがあります。

マッピング テーブルがユーザーの制御下にない場合は、アイテムまたはタグのいずれかに is_active フラグを使用して、クエリを実行できるかどうかを判断すると思います。

そのフラグを追加すると、人々はそれを使用することを忘れることを知っておいてください. 私は何度もそれを行ったことを知っています (「なぜそんなに多くのレコードを取得したのですか?何が欠けているのでしょうか?そうそう、is_active...)

于 2013-01-27T16:57:33.610 に答える