Lucas Franzen wrote:

>Uwe Grauer schrieb:
>
>
> > OK, i also give my 2cents:
> >
> > You have the Problem, that you need records witch really were deleted,
> > it's what i would call bad database design.
> > Why not do it in the following way:
> > Do not physically delete records. Mark them deleted.
> > This way you can still have the log of user-deletes. Sometimes
> > you will need it because for example in the bankers-business you have
> > to be able to tell from whom and when a record was deleted.
> > There are soo many possibilities to do this kind of work, that
> > i do not want to cont them now, but i really had to do it this way.
>
>And another 2c.
>
>If you don't want to mark them deleted and move (insert) them into a
>separate shadow table it's quite easy to set up the trigger that way
>that it will have a look at the seconds table if the record was already
>copied before writing it in there.
>
>I do just agree with Uwe that anything else if bad db design.
>
>Luc.
>
>

Hi Lucas,

yes, that's why i wrote "soo many possibilities".
I depends on your refrential integrity logic of the application,
if one way to do it will get a mess in the end.
So it will depend on your needs.

So one have to specify the needs, before one can decide on how to do it.
If one do not want to do it, one have to throw money at it, so that the
database (middle layer, transaction monitor, replication engine,
clustering, or what else)
will do it for you. Consider Oracle.

Uwe