The datatype in MSSQL would be ‘bit’, but for MySQL I’d typically use ‘tinyint’. I would only store a ‘0′ or ‘1′ in this column.

When I want to delete that row I simply UPDATE its value to ‘1′ meaning true, or yes…this is deleted.

Then when I’m SELECTing data from this table I make sure my WHERE condition has:

WHERE bIsDeleted <> 1

Make sure you don’t have NULL values in that column, otherwise your WHERE clause will need to also look for NULL and <> 1

Often a developer might have a column in a table who’s value is an indicator of that rows status, i.e. whether that row is ‘deleted’ or not.

For example if I had a Users table I might have a column called bIsDeleted which is a bit (or boolean) data type. The initial value of this column would be null or 0, indicating that the current record is NOT flagged as deleted and therefore is active.

If that user was to be deleted I would UPDATE the Users table setting that flag to 1 (i.e. the boolean value of ‘true’). Now my application will know that the user has been ‘deleted’, but my data has been retained.

e.g.
UPDATE Users
SET bIsDeleted = 1
WHERE UserId = 10

Hope that makes sense.

Can anybody explain this using an example
Thank you

Audit trails haven’t come up ofter but I think for your average mom-and-pop outfit this is just way overkill. They deleted something on accident even though you put the delete button way on the right of the page and added a popup stating “This record is being deleted” They still click it and call you for the magic pill.

Well i got it because everything is marked as deleted or what I’ve been doing more and more is IsActive = 808 or something you would normally never use. You got IsActive = 1 for normal content, 0 for InActive, but those items in 808 stand out in the database and since I still mark last updated by on the update, there is at lease a who was last here type mark on the record.

Very little work is done to make this happen. the button for delete still goes through the same update routine so I’m actually saving myself from having to create a delete routine. If the DB get’s too big, I’ll delete old records then manually.

Agreed, I always set my relationships during database design so referential integrity is enforced. This way you obviously couldn’t delete the parent record even if you wanted to, because a child exists.

Also I don’t use cascading deletes.

Automated systems can be in place that automatically purge old records as well as a mechanism that can be enabled to prevent deletion of records should a discovery process occur.