Comments on: The trouble with soft delete

By: Wesam Alalem

Wesam Alalem — Thu, 04 Feb 2010 15:05:15 +0000

thanks a lot,
Great points mentioned, I’ll keep this as reference.
Good luck,

By: Steven Quick

Steven Quick — Wed, 25 Nov 2009 04:01:52 +0000

Opps first paragraph above should have read:

From a database level perspective, the database itself can’t enforce that Job ID xyz should not be in both the Expired and the ActiveListing at the same time, not easily like with unique indexes and constraints on a single table.

By: Steven Quick

Steven Quick — Wed, 25 Nov 2009 03:59:19 +0000

The probably from a database level perspective it the database can’t enforce that Job ID xyz should never be in both the Expired and the ActiveListing itself easily.

It makes the sub type approach a little scary because you’re totally dependant on your domain/data services always doing the right thing… ie: Always remove the row from the ActiveListing after Inserting the row into the ExpiredListing.

By: Think Before Coding

Think Before Coding — Mon, 23 Nov 2009 16:02:55 +0000

The user usually don’t mean delete the row from the database (as udi is spotting).
Then, depending on the context, there are different technical way to do what the user is requesting.
*If you use a RDBMS* and if the data should not be used anymore in the context, delete the row, otherwise, mark it.

The important thing is that there are usually several contexts and thus models in an application. Don’t try to fit everything in a single model if you have several contexts with different requirements.
In a history reporting context, you’ll add new entries on a OrderCancelled event, in a context that work on current state, you’ll delete it, in a context whose goal is to track that the order has been cancelled on the shipping site, it’s still another story.

By: Reflective Perspective - Chris Alcock » The Morning Brew #482

Reflective Perspective - Chris Alcock » The Morning Brew #482 — Mon, 23 Nov 2009 11:18:51 +0000

[...] The trouble with soft delete – Richard Dingwall talks about the different techniques for implementing Soft Deletes, looking at the use cases, and some software patterns which offer similar capabilities [...]

By: Richard

Richard — Sun, 22 Nov 2009 00:01:07 +0000

@ erwin: a queue could be another table, or some other persistence mechanism. You’re right the system should support the business requirement record future-dated information — I was just suggesting it puts it aside in a special place until that date arrives and the item becomes active.

Likewise with historical data — keep it, but store it differently to the live stuff.

I’m 23 by the way!

By: erwin smout

erwin smout — Sat, 21 Nov 2009 23:07:33 +0000

Exceptionally good post if you really are what you claim”a young software developer”.

However.

There are two aspects I fundamentally disagree with :

“If a row doesn’t apply yet, put it in a queue until it does.”
“Keeping historical data”

If the USER (I mean, NOT the AUDITOR) of the application has a business requirement to be able to record future-dated information, then there is no way around the fact that you have to build support for that requirement.

If the USER (once again, NOT the AUDITOR) has a business requirement to be able to query historical data, then that historical data has to be considered as “operational data just like any other”, and there is no way around the fact that you have to include support for that requirement in your application.

(True temporal dbms’s would be a great help to do that, but they don’t exist.)

By: Waldo Jaquith - links for 2009-11-21

Waldo Jaquith - links for 2009-11-21 — Sat, 21 Nov 2009 23:02:39 +0000

[...] Richard Dingwall: The trouble with soft delete A good argument that having a "deleted" flag in a database is often a bad idea, and frequently nothing more than cargo cult programming. (The latter is true in my case.) (tags: sql database programming) [...]

By: Mark Harrison

Mark Harrison — Sat, 21 Nov 2009 21:22:00 +0000

Nice article, and some interesting points to consider.

I have some situations analagous to soft delete, and have created “where status = active” views so people won’t have to remember to do this themselves.

By: Richard

Richard — Sat, 21 Nov 2009 20:15:28 +0000

@ Matthew W: no references, that’s just what I’ve found from experience.

@ Kane: developers should definitely focus on the business scenario. Most of my posts are about DDD – I link to that same article!

@ David: fair point. Fixed.

BTW the class-per-table arrangement in this article is just one proposed solution, and not necessarily the best. Sharding, partitioning, indexed views, temporal databases etc are some other possibilities that might work better but are beyond the scope of this article (and my knowledge) to go in-depth on. Would be great to see some follow ups/benchmarks exploring this.