views:

40

answers:

2

Hello all!

I have a DB that stores different types of tasks and more items in different tables. In many of these tables (that their structure is different) I need a way to do it that the item has to be double-checked, meaning that the item can't be 'saved' (I mean of course it will be saved) before someone else goes in the program and confirms it.

What should be the right way to say which item is confirmed:

  1. Each of these tables should have a column "IsConfirmed", then when that guy wants to confirm all the stuff, the program walks thru all the tables and creates a list of the items that are not checked.
  2. There should be a third table that holds the table name and Id of that row that has to be confirmed.
  3. I hope you have a better idea than the two uglies above.
+2  A: 

Is the double-confirmed status something that happens exactly once for an entity? Or can it be rejected and need to go through confirmation again? In the latter case, do you need to keep all of this history? Do you need to keep track of who confirmed each time (e.g. so you don't have the same person performing both confirmations)?

The simple case:

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

When the first confirmation:

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

On second confirmation:

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

When rejected:

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

Now obviously your background job can only treat rows where Processed = 0 and ConfirmCount = 2. Then when it has processed that row:

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

If you have a more complex scenario than this, please provide more details, including the goals of the double-confirm process.

Aaron Bertrand
So you're saying that I have to add this col in each of the tables.I see.I thought about adding another table "Confirmations" and thru it know what rows (in the entire DB) need to be confirmed.
Shimmy
A central table might seem like a good idea but I find it hard to relate that to the actual tables. Will you have a column with the name of the table that is referenced? Or some kind of type column that indicates the type of entity? Since each entity will have to be processed separately anyway ((unless you are building kludgy dynamic SQL) then the central table doesn't really buy you much except avoiding adding new columns to the existing tables.
Aaron Bertrand
Basically I would like to do it that way (dynamically relating different types of entity-structures.The question is if placing a non-null bit column in each of these tables IsDoubleChecked etc. would it be worse?
Shimmy
Sorry, I'm not sure what your criteria are for "worse." You'll have to decide which method makes sense for your requirements.
Aaron Bertrand
thank u very much
Shimmy
+1  A: 

Consider adding a new table to hold the records to be confirmed (e.g. TasksToBeConfirmed). Once the records are confirmed, move those records to the permanent table (Tasks).

The disadvantage of adding an "IsConfirmed" column is that virtually every SQL statement that uses the table will have to filter on "IsConfirmed" to prevent getting unconfirmed records. Every time this is missed, a defect is introduced.

In cases where you need confirmed and unconfirmed records, use UNION.

This pattern is a little more work to code and implement, but in my experience, significantly improves performance and reduces defects.

Darryl Peterson