Additional field in a Database table for removal

Question

I created a database, in which I have some problems when I remove some data from the table.

Example Sales stand: I have a salesman who’s been fired and I want to remove him from the comic book but I can’t because that salesman has associated him with 1000 and such sales... And I can’t erase the 1000 and such sales because of the seller...

I know that to solve this problem, one of the solutions is to add a field to each table where when this data is removed this field goes to false or 0 and when it is active this field is to true or 1.

Question

What is this way of resolving? This is if there is a name for it

Example: if I say I will use "Singleton" in a class automatically who knows this Design Pattern you know what I’m gonna do.

Is there such a name for this way of solving?

Answer 1

In English, we simply say "mark as Deleted" (like, "mark as removed"), and in fact it’s a common practice. I don’t know any alternative terminology for this practice, but I could be mistaken. (a quick Google search brought me the term "soft delete", but that was the first time I saw the same)

By the way, there are other alternatives to what you intend to do, not necessarily better but are still options:

• Create a "special" seller whose function is to become the owner of every sale that becomes "orphaned" (more or less like our user Commune). Possible, although you miss some interesting statistics if you do so.

• Separating what is permanent from what is transitory: sometimes it can be interesting to keep a track record of what happened in the company, who went through it, who did what, etc., but at the same time it is necessary (by law, for example) that the personal data of an exemployee or former client are permanently removed after a certain time. The solution then is to have a separate table for "the seller" (only with "generic" fields, such as a UUID) and another for "the seller’s personal data" (first name, surname, address, contact phone number, list of documents, etc.) with foreign key to the first table.

  The first table never has data removed or even marked as removed. The second is where you search for active sellers (i.e. if you need a seller, look in the personal data table, not the master table), and once one of them leaves the company you can simply erase their data and the rest continues as is. In the future reports, it will be stated that "the seller f47ac10b-58cc-4372-a567-0e02b2c3d479 made a sale in the value of X on the Y date", etc.

Answer 2

Create a DATA_DA_DEMISSAO field, signal its output and keep the history.