タスクをダブルチェックする方法（DBに保存する方法）は？

Question

さまざまなテーブルにさまざまなタイプのタスクやより多くのアイテムを保存するDBがあります。これらのテーブルの多く（それらの構造が異なること）では、アイテムを再確認する必要があるという方法が必要です。つまり、アイテムを「保存することはできません」（もちろん保存されます）他の誰かがプログラムに参加して確認する前に。

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

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

Answer 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>;

今では明らかに、あなたのバックグラウンドジョブは処理された= 0の場合にのみ行を扱うことができます と CONDILCOUNT = 2次にその行を処理したとき：

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

これよりも複雑なシナリオがある場合は、Double-Confirmプロセスの目標を含む詳細を提供してください。

Answer 2

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

「isConfirmed」列を追加することの欠点は、テーブルを使用するほぼすべてのSQLステートメントが、未確認のレコードの取得を防ぐために「isConfirmed」でフィルタリングする必要があることです。これが見逃されるたびに、欠陥が導入されます。

確認された記録と未確認の記録が必要な場合は、Unionを使用してください。

このパターンは、コードと実装にはもう少し作業ですが、私の経験では、パフォーマンスを大幅に改善し、欠陥を軽減します。