0

I'm making a web app with Laravel and PostgreSQL where many records in almost all tables in the database need to be kept by historical reasons (users need to search old data for statistical reasons). Laravel provides soft-deleting working out-of-box, so why not to use this feature (soft deletion) as a mechanism for deactivating records in the database?

Is it a good idea? or is better to create a disabled_at field to mark a record as inactive/disabled instead of using the deleted_at field?

Using the Laravel's built-in soft delete feature is kinda easier due the existence of Eloquent's methods to retrieve or restore the soft deleted records.

Any help is really much appreciate it, thanks.

Dovahkiin
  • 1
  • 1
  • "why not to use this feature" - What would you do in contexts without Laravel, such as reports, e.g. in frameworks like Tableu? – J.D. Jul 13 '23 at 01:34
  • Hmm? To make a report the user will have the ability to decide if he/she wants to include deleted (or in this case, deactivated) records... But I think I got your point... certainly any person who see a deleted_at field in a db table should think "this is for marking it as deleted not deactivated"... and if I use this db in contexts where deleted_at must mean and only mean marked for deletion sure I'll need another field just to mark a record as deactivated but must not be deleted... so... in order to keep things standards(?) I suppose I should use a disabled_at field. – Dovahkiin Jul 13 '23 at 02:46
  • Yea, a few different reasons. You may also want to create a report for the end users that excludes the soft deleted rows. But in a framework outside of Laravel you wouldn't be able to if you depended on Laravel for your soft deletes, and didn't have a dedicated column. – J.D. Jul 13 '23 at 02:49

0 Answers0