On Thu, 19 Jun 2003, Matthew Nuzum wrote:
> Regarding backup history:
>
> I have an application designed for novices. Apparently it's easy to hit the
> "Delete" button, and then say yes to the "Are you sure you want to delete
> this?" question even when they don't want to. Therefore I simply mark a
> record as deleted. For example,
> UPDATE table SET deleted='t' WHERE something=true;
>
> Then my application logic pretends it doesn't really exist until two days
> later the user decides they want it back.
>
> It works very well for me.
>
But are you also taking care of the referential integrity issues, i.e. only
disallowing tuples with a deleted = true from being referenced to and ensuring
nothing references them at the time they are marked as deleted.
It is a useful idea but as I know from a current project it requires
reimplementing foreign key functionality. In this case the middleware only uses
functions, one per statement, and nothing else, so I have been able to do much
of this in those functions but it's still a pain. I even wrote a utility to
take some of the leg work out of generating and maintaining quite a few
functions but if I'd had time [and thought about these basically being foreign
key constraints] I'd have looked at the existing foreign key code and seen if I
could copy and amend it or just amend it in place.
--
Nigel Andrews