Volker Hetzer wrote:
> DA Morgan wrote:
>
>> Volker Hetzer wrote:
>>
>>> Hi!
>>> I've got a rather stupid constraint problem:
>>> There's a table with data on PCB symbols (like "7400" or "Resistor").
>>> Per symbol there's the number of pins on the symbol.
>>> Now, another table is supposed to have as many rows (per symbol)
>>> as there are pins.
>>> Is there any way I can have a constraint checking this?
>> Tom Kyte has dealt with this at least a few times and explained how
>> best to accomplish this. I'd suggest checking http://asktom.oracle.com.
> There is indeed something in there that could work:
> http://asktom.oracle.com/pls/ask/f?p=4950:8:11403979146324286545::NO::F4950_P8_DISPLAYID,F4950_P8_CRITERIA:42170695313022
>
> Ok, that question deals with a special case of 0 and 1 but I think that
> could be extended:
> The symbol table has one attribute with the pin count that
> should be there and one attribute with the current pin count.
> Then a trigger on the pin table updates the current count and
> a deferred constraint on the symbol table checks that they are
> identical at the end of ach transaction.
>
>> Get back if you don't find it.
After having thought about it a bit more it's only 9 out of 10.
All it takes to shoot down integrity is an update of the current
pin count which is not done by the trigger. All "normal" integrity
constraints are such that you can't break them using DML, after all
DML changes is what one is guarding against.
Right now the only way I can think of is preventing non-trigger
updates on the current pin count. Can I do that without a second
schema?
Is there a competely different, better way?
Lots of Greetings!
Volker
Received on Tue Jun 14 2005 - 01:00:29 CDT
