From: | Alban Hertroys <alban(at)magproductions(dot)nl> |
---|---|
To: | Robert Haas <Robert(dot)Haas(at)dyntek(dot)com> |
Cc: | David Fetter <david(at)fetter(dot)org>, pgsql-general(at)postgresql(dot)org |
Subject: | Re: complex referential integrity constraints |
Date: | 2007-02-26 09:15:21 |
Message-ID: | 45E2A529.2050609@magproductions.nl |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Robert Haas wrote:
> I don't understand what a weighted constraint would mean. Either the
> attacker_id can be a wolf, or it can't. Knowing that it is only 1%
> likely over the long haul is insufficient to disallow any particular
> transaction.
Basically I suggested to combine the constraint with a probability. If
the probability of one animal attacking another is 0% it can't attack
the other animal - that's a strict constraint. The other way around it
can, and you'll also immediately know how likely that is to happen.
An added bonus is that you can generalize certain constraints. If
certain animals are less than - say 25% - likely to attack other certain
other animals you could determine that the attacked animal is not in
fact prey. An example would probably be wolves attacking other wolves
(or predators in general). For relations that depend on an animal being
prey, a constraint would be that this number be <25%.
In this discussion it is also not entirely defined what attacking means.
Is a ram defending his horde from wolves attacking (wolves)?
I realise this all started from an analogy to a real problem, so most of
this is probably not very relevant to your actual problem. No less
interesting, though.
--
Alban Hertroys
alban(at)magproductions(dot)nl
magproductions b.v.
T: ++31(0)534346874
F: ++31(0)534346876
M:
I: www.magproductions.nl
A: Postbus 416
7500 AK Enschede
// Integrate Your World //
From | Date | Subject | |
---|---|---|---|
Next Message | Dave Page | 2007-02-26 09:32:11 | Re: [GENERAL] PostgreSQL on Windows Paper |
Previous Message | Ron Johnson | 2007-02-26 08:46:04 | Re: General Ledger db design |