Additional field in a table Database for removal

Question

Additional field in a table Database for removal

Navigation

#1 by (5 votes)
#2 by (0 votes)

7

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

Example Sales Stand: I have a seller who was fired and I want to remove it from the bd but I can not because this seller has associated him with 1000 and such sales ... And I can not delete 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 in which when this data is removed this field becomes false or 0 and when it is active this field is true or 1.

Question

What is the name of this way of solving it? that is if there is a name for it

Example: If I say that I will use " Singleton " in a class automatically who knows this Design Pattern knows what I am going to do.

Is there a name like this for this way of solving it?

terminologia

asked by anonymous 24.10.2014 / 12:43

2 answers

0

Create a field DATA_DA_DEMISSAO, signal the output of the field and maintain the history.

25.10.2014 / 02:46

Structuring the router class in PHP with MVC Creating a java interpreter for android?

score 5 · Accepted Answer

In English, we simply say "mark as deleted" (type, "mark as removed"), and in fact it is a common practice. I do not know any alternative terminology for this practice, but I may be wrong. (a quick search on Google brought me the term "soft delete", but this 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" salesperson whose function is to become the owner of every sale that becomes "orphaned" (more or less like our user Community ). Possible although you will lose some interesting stats if you do it this way.
Separate what is permanent from what is transient: sometimes it may be interesting to keep a history of what happened in the company, who passed through it, who did what, etc., but at the same time it is necessary (by law, by personal data of a former employee 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 "personal data of the seller" (name, surname, address, 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 look for active sellers (ie if you need a salesperson, look in the personal data table, not the master table), and once one of them leaves the company you can simply erase your data and the rest goes on how are you doing. In future reports, it will be noted that "seller f47ac10b-58cc-4372-a567-0e02b2c3d479 made a sale of the value of X on the date Y", etc.