I'm developing a sort of CMS. In it, users can create "Customers". For whatever reason, a user might want to delete that Customer. Maybe because the Customer was created in error, or maybe they think the Customer will never return again, or maybe they're just OCD and want a nice clean system.
However, Customers are referenced in various places throughout the system. For example, Bookings link to Customers. If a Customer is linked to a Booking and then later deleted, then the Booking will essentially be corrupt. It's now missing a vital piece of historical information. To prevent this, I've created foreign key constraints at a database level.
Here's what I'm thinking: I can leverage these constraints by attempting to delete the Customer when requested, but upon failing perform a soft delete instead. This way I can maintain referential integrity but also prevent cruft build up from soft-deleted Customers that aren't actually used anywhere.
- If a Customer is not referenced anywhere in the system, it will perform a real hard delete
- If the Customer is referenced somewhere, it will perform a soft delete (i.e. flag the record as deleted but keep it)
Is this okay? My concern is that you don't really know what the "Delete" button will do until you press it, but from a user's point of view it doesn't really matter -- either way the Customer will disappear from the index. Are there other issues?