I agree that the "hard vs. soft delete" debate is pointless. It seems the article sets up a false dilemma. The interesting thing is how to deal with archive da

I agree that the "hard vs. soft delete" debate is pointless. It seems the article sets up a false dilemma. The interesting thing is how to deal with archive data. There are a few patterns, but the one presented many times in this article is the "log it" pattern (if it has an official name, please let me know). Basically, this transforms all the data into a series of transactions, each of which is stored. It can occur at the database level (log each changing query, e.g. insert, updated, delete). At the data level (columns for is-filled, is-backordered, and so on, the soft delete in the article). At the application level (each transaction is in a different row, what it means is away from the data itself). Really it comes down to how often the data will need to be accessed, and how dynamically it needs to be queried. In the modern age of hadoop clusters everywhere, and clouds being cheap, it may actually be best to keep the database as a maintainer of current state, and the transaction log as the historian (alternative 1 above), shipping off the logs for data-mining on the cluster at the analyst's leisure. The part I find amusing is: depending on which angle you come from, this could be a hard or soft delete :).