From: | Ron Johnson <ron(dot)l(dot)johnson(at)cox(dot)net> |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: General Ledger db design |
Date: | 2007-02-26 08:46:04 |
Message-ID: | 45E29E4C.3080100@cox.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 02/26/07 01:39, Karl O. Pinc wrote:
>
> On 02/25/2007 06:21:45 PM, Kenneth Downs wrote:
>> Martin Winsler wrote:
>
[snip]
> The above proposal takes care of the data
> structure/referential integrity
> issues, but does not solve the data integrity issues.
>
> The only way, at present, to solve the data integrity
> issues is to write a FOR EACH STATEMENT trigger to be sure that
> all the rows agree with each other and everything balances.
> But this can only be done after all the data goes into the database.
[snip]
> FWIW, I have long lusted after a per-row trigger that would
> fire on transaction commit to solve these problems.
> (Or any sort of trigger with access to the row
> data so that it can be checked.)
> I couldn't say whether such triggers are technically feasible,
> but I'm pretty sure nobody's
> interested enough to do the implementation.
Why wouldn't deferred (commit time) constraints be adequate to the
task? That's why they were designed.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFF4p5LS9HxQb37XmcRAqRlAJ4x1I/R2C/OHc+qLwZpz81jJRcRewCeJDz5
/TZzI8PkALsb/YSIl7wyl+4=
=OTZZ
-----END PGP SIGNATURE-----
From | Date | Subject | |
---|---|---|---|
Next Message | Alban Hertroys | 2007-02-26 09:15:21 | Re: complex referential integrity constraints |
Previous Message | Karl O. Pinc | 2007-02-26 07:39:43 | Re: General Ledger db design |