BEST RELATIONAL DATABASES APPROACH FOR DELETE: use DELETE or use a valid/non-valid COLUMN?

Question

When it comes to databases , which is the best technical approach to use when a user want's to delete his profile/delete some of his products from a shopping card:

1. Actually delete the rows from the relational tables that have his id, using DELETE .

2. Don't DELETE any row, but change the value of a boolean COLUMN/enum COLUMN (let's call it valid/non-valid) from true to false/0 to 1 - this implies that whenever you wan't to select all the existing users/products you need a WHERE clause to filter only the ones that have true on this particular COLUMN.

I am asking this because I have spoken with two experienced DB developers and when I told them that I am really deleting rows from the tables in my MySQL database, they were shocked! One of them told me that she was taught never to delete already inserted rows from tables.

So I would like to find which is the best professional approach for this action.

Answer 1

Perhaps they were not answering the technical question, but rather the business question. Deleting a row is bad (businesswise) if you ever need to recover the history of what happened to the profile/shoppingcart/whatever.

From a technical point of view, there is not a strong argument either way.

Flagging a row as "deleted" leaves clutter in the table and clutters SELECTs with AND deleted=0 in the WHERE clause. If 'most' of the table is deleted, performance suffers.

Actually DELETEing the row loses history (as mentioned), takes effort, and fragments the table. The effort is minor. The fragmentation, especially if you are using InnoDB (which you should be), is not worth worrying about.

A third option is to DELETE it from the main table and INSERT it into an archive table with a similar schema. This is more work: DELETE + INSERT at delete time, UNION when you need to see both active and deleted rows, etc. PARTITION could be used, but I would argue that it does not help. I say similar because you might want to avoid UNIQUE keys (and other things) that could trip you up if, for example, the use vacillates so much in his shopping cart that an identical row is archived twice.

Look at it this way... Bank records are very permanent; shopping carts are very transient (until the purchase is consummated); other things are somewhere in between. Choose actual DELETE versus a flag based on business reasons, more than MySQL reasons.

(I would be interested to hear the developers' reactions to my comment. I could be missing something.)