Removing Data is not a Recommended Practice
Removing a line or an entity is rarely simple. The operation affects not only the model data but also its shape. That's why we use foreign keys to ensure that the items in a Purchase Order do not go without an associated Purchase Order. And this is the simplest case. ...
When working with logical removals, it is easy to get into situations where we have corrupted data since a customer's UltimaOrder (a simple optimization) may point to a Purchase Order that has been logically removed.
Let's say that our marketing department decides to remove a Product from the catalog. Should we remove all Purchase Orders that contain this Product? Should we also remove all Invoices related to these orders? Going further, should we recalculate the company's profits?
Let no one let him do this.
In fact, 'removing' a Product means that it will be discontinued. We no longer want to sell this line of Products. We want to get rid of the stock we have and never buy from our supplier again. The product should not appear in user searches, but warehouse staff still have to manage these items. Anyway it's a lot easier to just say 'remove'.
Purchase orders are not removed - they are canceled. There may even be a fee if the order is canceled too late.
Employees are not removed - they are fired (or retired). Termination can also be handled in the system.
Jobs are not removed - they are filled.
In all cases we should focus on the task that the user wants to perform rather than the technical action that should be performed on an entity. In almost all situations, more than one entity will be taken into account.
The most correct in all cases is the creation of a field that allows to know in what state the current information is, so no data will ever be lost, allowing in the future to be analyzed for some possible decision making. >
Data is of extreme value in any business, especially IT-related, always keep it.