Question

I am working in a project where database items are not deleted, but only marked as deleted. Something like this:

id   name     deleted ---  -------  -------- 1    Thingy1  0 2    Thingy2  0 3    Thingy3  0 

I would like to be able to define something like a UNIQUE constraint on the name column. Seems easy, right?

Let’s imagine a scenario in which ‘Thingy3’ is deleted, and a new one is created (perhaps years later). We get:

id   name     deleted ---  -------  -------- 1    Thingy1  0 2    Thingy2  0 3    Thingy3  1 ... 100  Thingy3  0 

From the user’s point of view, he deleted an item and created a new one. Much like deleting a file, and creating a new file. So it’s obvious to him that the new item is unrelated and unattached to any data connected to the old item.

That’s already handled, since the DB only cares about the id, and since the new item has an id of 100 instead of 3, they are utterly different.

My difficulty arises when I want to prevent the user from creating another ‘Thingy3’ item. If I had a UNIQUE constraint that only looked at items that aren’t marked deleted, then I would have solved one problem.

(Of course, then I’d have to deal with what happens when someone does an undo of the delete…)

So, how can I define that sort of a constraint?

Answer 1

You could add the id value to the end of the name when a record is deleted, so when someone deletes id 3 the name becomes Thingy3_3 and then when they delete id 100 the name becomes Thingy3_100. This would allow you to create a unique composite index on the name and deleted fields but you then have to filter the name column whenever you display it and remove the id from the end of the name.

Perhaps a better solution would be to replace your deleted column with a deleted_at column of type DATETIME. You could then maintain a unique index on name and deleted at, with a non-deleted record having a null value in the deleted_at field. This would prevent the creation of multiple names in an active state but would allow you to delete the same name multiple times.

You obviously need to do a test when undeleting a record to ensure that there is no row with the same name and a null deleted_at field before allowing the un-delete.

You could actually implement all of this logic within the database by using an INSTEAD-OF trigger for the delete. This trigger would not delete records but would instead update the deleted_at column when you deleted a record.

The following example code demonstrates this

CREATE TABLE swtest (       id          INT IDENTITY,       name        NVARCHAR(20),       deleted_at  DATETIME   )   GO   CREATE TRIGGER tr_swtest_delete ON swtest   INSTEAD OF DELETE   AS   BEGIN       UPDATE swtest SET deleted_at = getDate()       WHERE id IN (SELECT deleted.id FROM deleted)     AND deleted_at IS NULL      -- Required to prevent duplicates when deleting already deleted records   END   GO    CREATE UNIQUE INDEX ix_swtest1 ON swtest(name, deleted_at)    INSERT INTO swtest (name) VALUES ('Thingy1')   INSERT INTO swtest (name) VALUES ('Thingy2')   DELETE FROM swtest WHERE id = SCOPE_IDENTITY()   INSERT INTO swtest (name) VALUES ('Thingy2')   DELETE FROM swtest WHERE id = SCOPE_IDENTITY()   INSERT INTO swtest (name) VALUES ('Thingy2')    SELECT * FROM swtest   DROP TABLE swtest   

The select from this query returns the following

 id      name       deleted_at 1       Thingy1    NULL 2       Thingy2    2009-04-21 08:55:38.180 3       Thingy2    2009-04-21 08:55:38.307 4       Thingy2    NULL 

So within your code you can delete records using a normal delete and let the trigger take care of the details. The only possible issue (That I could see) was that deleting already deleted records could result in duplicate rows, hence the condition in the trigger to not update the deleted_at field on an already deleted row.