Subject | Re: [firebird-support] Delete advice |
---|---|
Author | Helen Borrie |
Post date | 2008-08-30T08:20:02Z |
At 16:55 30/08/2008, you wrote:
Better that you design your new structures with "before" triggers that perform the necessary operations on incoming data (whether by insert or by update) and not even visit the scenario where you will store records that are subsequently deleted within the same transaction. One can see your proposed approach resulting in a birds-nest of record versions and unexpected outcomes with no trail.
With a client/server model:
-- collect data from client and pass it across the wire, where it is written to the database and is visible to only this transaction
-- perform necessary calculations in triggers, storing intermediate values in local variables
-- finally, provide the resulting final new.values to the affected table.
After triggers can update any other tables affected by the operations on this one.
....Finally committing the whole operation. No deletes.
./heLen
>Hi !It's very unclear from this and other postings just what you want to achieve...however, it seems to make no sense to be deleting and recreating rows as a way of arriving at an endpoint.
>I have an old application that works with .mdb file and I have to rewrite it and this time I'll use Firebird for data storing.Application does some calculations in one table,method used : delete every row and add new calculated rows,calculation is done several times on a day.I think this will grow my database and I don't like this way and I plan to use one field active_,to set 0 before calculation,then I'll use Update or Insert with active_=1 and finally I'll delete only rows with active_=0.
> Am I doing right this way?
Better that you design your new structures with "before" triggers that perform the necessary operations on incoming data (whether by insert or by update) and not even visit the scenario where you will store records that are subsequently deleted within the same transaction. One can see your proposed approach resulting in a birds-nest of record versions and unexpected outcomes with no trail.
With a client/server model:
-- collect data from client and pass it across the wire, where it is written to the database and is visible to only this transaction
-- perform necessary calculations in triggers, storing intermediate values in local variables
-- finally, provide the resulting final new.values to the affected table.
After triggers can update any other tables affected by the operations on this one.
....Finally committing the whole operation. No deletes.
./heLen