J
John Rivers
Hello,
I think this will apply to alot of web applications:
users want the ability to delete a record in table x
this record is related to records in other tables
and those to others in other tables etc.
in other words we must use cascade delete to do
this in one go
my problem is that users make mistakes
and one day they will accidently delete the wrong
record in table x
and the cascade delete will take out a large chunk
of the database
and they will ring me and say "we want to put it back"
that got me thinking about some approaches
1 - have a little ui that shows them all the records
they are about to delete so they think see the
consequences of their actions, this will lower the
number of mistakes
2 - leverage the current interface to guide them through
the cascade manually (ie: not in sql) so that they are
forced to confront the consequences bit by bit
and it takes a long time so it is dull and they won't
do it in a whim
but then i realised whatever i do they will make mistakes
and why write code when you don't have to
thus i came up with this approach that seems to fulfill
all requirements and take almost no coding whatosever:
enable cascade delete in the database
create a delete trigger on the table in question
that writes an entry into a DeleteLog table
including three pieces of information:
timestamp (of the sql box!)
tablename (of the table with the record to be deleted)
recordid (of the deleted record or records)
those two things wrapped in a transaction
to stop the risk of updates to the target
record after the log entry and before the delete
now!
users can delete whatever they like
and when they make a mistake (infrequently)
i can use a prewritten script to do a point
in time restore of the database
(to a different dbname - i call this docking)
using timestamp in the deletelog table
and run an easy but boring to write script that pulls
the data back in
what do you think?
I think this will apply to alot of web applications:
users want the ability to delete a record in table x
this record is related to records in other tables
and those to others in other tables etc.
in other words we must use cascade delete to do
this in one go
my problem is that users make mistakes
and one day they will accidently delete the wrong
record in table x
and the cascade delete will take out a large chunk
of the database
and they will ring me and say "we want to put it back"
that got me thinking about some approaches
1 - have a little ui that shows them all the records
they are about to delete so they think see the
consequences of their actions, this will lower the
number of mistakes
2 - leverage the current interface to guide them through
the cascade manually (ie: not in sql) so that they are
forced to confront the consequences bit by bit
and it takes a long time so it is dull and they won't
do it in a whim
but then i realised whatever i do they will make mistakes
and why write code when you don't have to
thus i came up with this approach that seems to fulfill
all requirements and take almost no coding whatosever:
enable cascade delete in the database
create a delete trigger on the table in question
that writes an entry into a DeleteLog table
including three pieces of information:
timestamp (of the sql box!)
tablename (of the table with the record to be deleted)
recordid (of the deleted record or records)
those two things wrapped in a transaction
to stop the risk of updates to the target
record after the log entry and before the delete
now!
users can delete whatever they like
and when they make a mistake (infrequently)
i can use a prewritten script to do a point
in time restore of the database
(to a different dbname - i call this docking)
using timestamp in the deletelog table
and run an easy but boring to write script that pulls
the data back in
what do you think?