Comments on: The trouble with soft delete

By: Relational database versioning strategies | JonBlog

Relational database versioning strategies | JonBlog — Sun, 27 Nov 2011 11:39:56 +0000

[...] of a unversioned table. It also adds a layer of complexity to all queries on the table (see here). The Propel ORM team has also noted several problems with the approach, and recommends an archive [...]

By: Ranu Mandan

Ranu Mandan — Mon, 19 Sep 2011 16:50:39 +0000

there is one more way of handling archived data , is by writing a purging job against an isdeleted = true records

By: Stefan Bundy

Stefan Bundy — Sat, 06 Aug 2011 09:52:57 +0000

Thanks for the post. I’m bookmarking your blog and will certainly return!

By: 77: TZ Discussion – TWaT (This Week about Tech)

77: TZ Discussion – TWaT (This Week about Tech) — Mon, 11 Oct 2010 05:14:55 +0000

[...] met and their early experiences using Agile methods, Alex’s work with Formula One racing, whether or not soft deletes are a bad idea, InnoDB vs MyISAM, taking advantage of micro opportunities, a [...]

By: Tarek Mahmud Apu

Tarek Mahmud Apu — Thu, 05 Aug 2010 05:58:53 +0000

It’s a nice post. Thanks a lot.

I have faced lots of problem on this issue. To maintain foreign key integrity and for reporting purposes, normally we change the status to “delete”.

I like the technique of storing the inactive data in separate table than the soft delete. But do u think creating view based on status can give better solution?

I liked that you mentioned “developers should definitely focus on the business scenario”. Sometimes client force to do that because they think this is the standard way though they need not use the soft delete.. so it causes some extra effort on developing.

By: Ron

Ron — Wed, 04 Aug 2010 11:01:06 +0000

Excellent!

From my experience, end users want to know what happened (the history of actions), so it is better to keep the deleted items in a separate table instead of implementing soft-delete.

implementing soft delete requires extra attention to primary database table to delete old rows and if your application is a huge one that inserts huge data per minute, soft-delete will definitely affect performance.

By: Nalin Jayasuriya

Nalin Jayasuriya — Fri, 11 Jun 2010 00:09:30 +0000

There is another downside to soft delete with Microsoft’s Entity Framework and DomainService usage.

As of Visual Studio 2010 (and EF 4), there is no simple way to expressing fetching primary entities while ‘including’ related entities and excluding the ‘soft deleted’ related entities. There is no syntax that expresses this requirement in the Linq to Entities model.

One more reason to re-consider having that ‘isDeleted’ flag!

- Nalin J

By: Are You Soft on Your Deletes? | Eddie Awad's Blog

Are You Soft on Your Deletes? | Eddie Awad's Blog — Mon, 15 Mar 2010 14:02:13 +0000

[...] Good discussion followed which included a couple of interesting links: What is the best way to implement soft deletion? and 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.