0

さまざまな種類のタスクとより多くのアイテムをさまざまなテーブルに格納する DB があります。これらのテーブルの多く (構造が異なる) では、アイテムをダブルチェックする必要があります。つまり、アイテムを「保存」することはできません (もちろん保存されます)。他の誰かがプログラムに参加して確認する前に。

どのアイテムが確認されたかを言う正しい方法は何ですか:

  1. これらの各テーブルには「IsConfirmed」列が必要です。その人がすべてのものを確認したい場合、プログラムはすべてのテーブルを調べて、チェックされていない項目のリストを作成します。
  2. 確認する必要がある行のテーブル名と ID を保持する 3 番目のテーブルが必要です。
  3. 上記の2つの醜いものよりも優れたアイデアがあることを願っています.
4

2 に答える 2

2

二重確認されたステータスは、エンティティに対して1回だけ発生するものですか？または、拒否されて再度確認を行う必要がありますか？後者の場合、この履歴をすべて保持する必要がありますか？毎回誰が確認したかを追跡する必要がありますか（たとえば、同じ人が両方の確認を実行しないようにするため）？

単純なケース：

ALTER TABLE dbo.Table ADD ConfirmCount TINYINT NOT NULL DEFAULT 0;
ALTER TABLE dbo.Table ADD Processed BIT NOT NULL DEFAULT 0;

最初の確認時：

UPDATE dbo.Table SET ConfirmCount = 1 WHERE PK = <PK> AND ConfirmCount = 0;

2回目の確認時：

UPDATE dbo.Table SET ConfirmCount = 2 WHERE PK = <PK> AND ConfirmCount = 1;

拒否された場合：

UPDATE dbo.Table SET ConfirmCount = 0 WHERE PK = <PK>;

これで、バックグラウンドジョブは、Processed=0およびConfirmCount=2の行のみを処理できるようになりました。次に、その行を処理すると、次のようになります。

UPDATE dbo.Table SET Processed = 1 WHERE PK = <PK>;

これよりも複雑なシナリオがある場合は、二重確認プロセスの目標など、詳細をお知らせください。

于 2009-10-18T22:08:47.170 に答える
1

確認するレコードを保持するために新しいテーブルを追加することを検討してください（例：TasksToBeConfirmed）。レコードが確認されたら、それらのレコードを永続テーブル（タスク）に移動します。

「IsConfirmed」列を追加することの欠点は、テーブルを使用する実質的にすべてのSQLステートメントが、未確認のレコードを取得しないように「IsConfirmed」でフィルタリングする必要があることです。これを見逃すたびに、欠陥が発生します。

確認済みおよび未確認の記録が必要な場合は、UNIONを使用してください。

このパターンは、コーディングと実装に少し手間がかかりますが、私の経験では、パフォーマンスが大幅に向上し、欠陥が減少します。

于 2009-10-20T12:14:25.270 に答える