From: | Ted Byers <r(dot)ted(dot)byers(at)rogers(dot)com> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | SQL design pattern for a delta trigger? |
Date: | 2007-12-06 20:36:44 |
Message-ID: | 325425.54760.qm@web88314.mail.re4.yahoo.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
IS there such a thing? I can be the first to consider
this.
What I am aiming for is a solution with a couple
coupled tables, one of which represents state through
time and the other represents transactions or deltas
on the state. With one field (a floating point
number) in the state table (or should I say a number
for each id field), it obviously has a time interval
for which it is valid: a start time and an end time.
What I am after is a situation where the moment a
record is inserted in the deltas table, a trigger
function first looks to see if the id provided
presently has a state in the state table. If not,
then it creates one. Then, the end date for that
state record gets set to the current time and a new
record is inserted with the new state (computed by
applying the delta to the value in the previous record
for the state), the current date as the start date and
null for the end date.
This seems like an obvious thing to try, but I am
floundering a little and am therefore wondering if
anyone has seen an SQL design pattern that talks about
this, and an url where I can see such a discussion
and, better, an example. The first concern is to
ensure that every record inserted into the deltas
table is immediately reflected in the state table, and
the second is that the history of state can be
reconstructed from a suitable query on the state
table.
I can do this easily in client code, but isn't this
the sort of thing best suited to living within the
database itself?
Thanks
Ted
From | Date | Subject | |
---|---|---|---|
Next Message | Gregory Stark | 2007-12-06 20:49:20 | Re: aggregate and order by |
Previous Message | A.M. | 2007-12-06 20:32:58 | Re: Continual Postgres headaches... |