0Day Forums
What is the best way to implement soft deletion? - Printable Version

+- 0Day Forums (https://zeroday.vip)
+-- Forum: Coding (https://zeroday.vip/Forum-Coding)
+--- Forum: Database (https://zeroday.vip/Forum-Database)
+--- Thread: What is the best way to implement soft deletion? (/Thread-What-is-the-best-way-to-implement-soft-deletion)

Pages: 1 2


RE: What is the best way to implement soft deletion? - slobdoy - 07-20-2023

Having `is_deleted` column is a reasonably good approach.
If it is in Oracle, to further increase performance I'd recommend partitioning the table by creating a list partition on `is_deleted` column.
Then deleted and non-deleted rows will physically be in different partitions, though for you it'll be transparent.

As a result, if you type a query like

SELECT * FROM table_name WHERE is_deleted = 1
then Oracle will perform the 'partition pruning' and only look into the appropriate partition. Internally a partition is a different table, but it is transparent for you as a user: you'll be able to select across the entire table no matter if it is partitioned or not. But Oracle will be able to query **ONLY the partition it needs**. For example, let's assume you have 1000 rows with `is_deleted = 0` and 100000 rows with `is_deleted = 1`, and you partition the table on `is_deleted`. Now if you include condition

WHERE ... AND IS_DELETED=0
then Oracle will ONLY scan the partition with 1000 rows. If the table weren't partitioned, it would have to scan 101000 rows (both partitions).


RE: What is the best way to implement soft deletion? - elleryfslcgmz - 07-20-2023

I would lean towards a `deleted_at` column that contains the **datetime of when the deletion took place**. Then you get a little bit of free metadata about the deletion. For your `SELECT` just get rows `WHERE deleted_at IS NULL`


RE: What is the best way to implement soft deletion? - Sirallanltat - 07-20-2023

@AdditionalCriteria("this.status <> 'deleted'")

put this on top of your `@entity`

[To see links please register here]




RE: What is the best way to implement soft deletion? - Sirgeotechnical210 - 07-20-2023

Use a view, function, or procedure that checks `is_deleted = 0`; i.e. don't select directly on the table in case the table needs to change later for other reasons.

And index the `is_deleted` column for larger tables.

Since you already have an audit trail, tracking the deletion date is redundant.


RE: What is the best way to implement soft deletion? - Mrphagocyter658 - 07-20-2023

Careful of soft-deleted records causing uniqueness constraint violations.
If your DB has columns with unique constraints then be careful that the prior soft-deleted records don’t prevent you from recreating the record.

Think of the cycle:

1. create user (login=JOE)
2. soft-delete (set deleted column to non-null.)
3. (re) create user (login=JOE). ERROR. LOGIN=JOE is already taken


Second create results in a constraint violation because login=JOE is already in the soft-deleted row.

Some techniques:
1. Move the deleted record to a new table.
2. Make your uniqueness constraint across the login and deleted_at timestamp column

My own opinion is +1 for moving to new table. It takes lots of
discipline to maintain the *AND delete_at = NULL* across all your
queries (for all of your developers)