Comments on: The trouble with soft delete http://richarddingwall.name/2009/11/20/the-trouble-with-soft-delete/ The adventures of a young kiwi software developer in London Thu, 10 May 2012 16:20:46 +0000 hourly 1 http://wordpress.org/?v=3.3.2 By: Richard http://richarddingwall.name/2009/11/20/the-trouble-with-soft-delete/comment-page-1/#comment-66451 Richard Sun, 29 Apr 2012 12:51:33 +0000 http://richarddingwall.name/?p=1909#comment-66451 @Brian: move the archive data into a separate archive/reporting store, denormalized, read-optimized and including active and inactive data. Depending on the size and constraints, this could simply be a separate denormalized table, or a separate schema, a separate DB or even a cube or something. But basically the idea is to separate your transactional (live, normalized, write-optimized) data from historical reporting data (inactive, denormalized, read-optimized). If you try to do both in the same table, concerns will leak from one side to the other (e.g. reports will have to do too many JOINs, and the write side will have to have WHERE Active = 1 all over the place). @Brian: move the archive data into a separate archive/reporting store, denormalized, read-optimized and including active and inactive data.

Depending on the size and constraints, this could simply be a separate denormalized table, or a separate schema, a separate DB or even a cube or something. But basically the idea is to separate your transactional (live, normalized, write-optimized) data from historical reporting data (inactive, denormalized, read-optimized). If you try to do both in the same table, concerns will leak from one side to the other (e.g. reports will have to do too many JOINs, and the write side will have to have WHERE Active = 1 all over the place).

]]> By: Brian Bokor http://richarddingwall.name/2009/11/20/the-trouble-with-soft-delete/comment-page-1/#comment-63135 Brian Bokor Tue, 10 Apr 2012 04:40:37 +0000 http://richarddingwall.name/?p=1909#comment-63135 Do you have a good example of how you might attack needing data and associations around for reporting, but don't actually need the record visible? I guess what I mean is how having a status on a table or an archive table seems to really bring the same complexities from my view point. Either it is more if statements or more intense SQL joins and given most bottlenecks always seem to come from the database with crap SQL, I think i would rather see more if else. Do you see an easier way to minimize joins and scenarios for data that has to be around for years (like PCI Compliant Service)...data mining would be terrible. Just wanted some thoughts, reactions?? Do you have a good example of how you might attack needing data and associations around for reporting, but don’t actually need the record visible? I guess what I mean is how having a status on a table or an archive table seems to really bring the same complexities from my view point. Either it is more if statements or more intense SQL joins and given most bottlenecks always seem to come from the database with crap SQL, I think i would rather see more if else. Do you see an easier way to minimize joins and scenarios for data that has to be around for years (like PCI Compliant Service)…data mining would be terrible. Just wanted some thoughts, reactions??

]]> By: Relational database versioning strategies | JonBlog http://richarddingwall.name/2009/11/20/the-trouble-with-soft-delete/comment-page-1/#comment-48117 Relational database versioning strategies | JonBlog Sun, 27 Nov 2011 11:39:56 +0000 http://richarddingwall.name/?p=1909#comment-48117 [...] 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 [...] [...] 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 http://richarddingwall.name/2009/11/20/the-trouble-with-soft-delete/comment-page-1/#comment-42092 Ranu Mandan Mon, 19 Sep 2011 16:50:39 +0000 http://richarddingwall.name/?p=1909#comment-42092 there is one more way of handling archived data , is by writing a purging job against an isdeleted = true records there is one more way of handling archived data , is by writing a purging job against an isdeleted = true records

]]> By: Stefan Bundy http://richarddingwall.name/2009/11/20/the-trouble-with-soft-delete/comment-page-1/#comment-38571 Stefan Bundy Sat, 06 Aug 2011 09:52:57 +0000 http://richarddingwall.name/?p=1909#comment-38571 Thanks for the post. I'm bookmarking your blog and will certainly return! Thanks for the post. I’m bookmarking your blog and will certainly return!

]]> By: 77: TZ Discussion – TWaT (This Week about Tech) http://richarddingwall.name/2009/11/20/the-trouble-with-soft-delete/comment-page-1/#comment-17559 77: TZ Discussion – TWaT (This Week about Tech) Mon, 11 Oct 2010 05:14:55 +0000 http://richarddingwall.name/?p=1909#comment-17559 [...] 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 [...] [...] 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 http://richarddingwall.name/2009/11/20/the-trouble-with-soft-delete/comment-page-1/#comment-15885 Tarek Mahmud Apu Thu, 05 Aug 2010 05:58:53 +0000 http://richarddingwall.name/?p=1909#comment-15885 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. 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 http://richarddingwall.name/2009/11/20/the-trouble-with-soft-delete/comment-page-1/#comment-15860 Ron Wed, 04 Aug 2010 11:01:06 +0000 http://richarddingwall.name/?p=1909#comment-15860 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. 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 http://richarddingwall.name/2009/11/20/the-trouble-with-soft-delete/comment-page-1/#comment-14861 Nalin Jayasuriya Fri, 11 Jun 2010 00:09:30 +0000 http://richarddingwall.name/?p=1909#comment-14861 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 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 http://richarddingwall.name/2009/11/20/the-trouble-with-soft-delete/comment-page-1/#comment-12918 Are You Soft on Your Deletes? | Eddie Awad's Blog Mon, 15 Mar 2010 14:02:13 +0000 http://richarddingwall.name/?p=1909#comment-12918 [...] 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. [...] [...] 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. [...]

]]>