Saqib Ali wrote:
Hello All,
What are best practices for deleting records in a DB. We need the
ability to restore the records.
Two obvious choices are:
1) Flag them deleted or undeleted
2) Move the deleted records to seperate table for deleted records.
The first is what I like more.
While in the first to mark as deleted (or restore), you only have to
change one column, and in the second, you have to move (and move again
to restore) from one table to another. Getting the value from the normal
value to store it in the second could lead to a problem
Implement the first in a developed schema, is just add a column of type
bool (for example) with the default beeing not deleted.
The second has the other problem of a change in the schema of the normal
table has to be done in the deleted values table.
We have a complex schema. However the the records that need to be
deleted and restored reside in 2 different tables (Table1 and Table2).
This lets you to have two different tables of deleted values.
Table2 uses the primary key of the Table1 as the Foriegn key. The
Primary key for Table1 is auto-generated. This make the restoring with
the same primary key impossible, if we move deleted data to a
If you mean "The Primary key for Table1 is auto-generated" by using
auto_increment, it is not impossible. You can just copy the entire
contents of the row.
different table. However if we just flag the record as deleted the
restoring is quite easy.
As I said.
Any thoughts/ideas ?
Just my opinion, and it seems to be the opinion of mambo developers, as
they implement the deletion of values to restore like this way, and they
have also a published column. If they have done this they would need 4
tables: published_and_not_deleted, published_and_deleted,
not_published_and_not_deleted and not_published_and_deleted.
I would say that the second is very bad.
--
Nuno Pereira
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
