Implementing complicated constraints

[Agoston Bejo]

Hi, I'm having trouble with implementing some constraints on the database
level. An example:

--Table A(AID, BID ref. B.BID, ATXT)
--Table B(BID, CID ref. C.CID)
--Table C(CID)

upon insertion into or updating in A I would like to force that ATXT is
unique with respect to CID, i.e.

SELECT COUNT(*) FROM A,B,C
WHERE A.BID = B.BID
AND B.CID = CID
AND CID = fn_get_cid_for_ bid(:new.BID)
AND A.ATXT = :new.ATXT
AND A.AID <> :new.AID

should be 0.

This I cannot force with a check constraint since it is not allowed to
contain subqueries.
If I try to write a trigger that checks the above condition and raises an
application error, then I always stumble upon the "table is mutating,
trigger/function may not see it" -type error, since it involves a select on
the table that is being changed at the time.

However, it would be better to implement such a constraint on the database
level, rather than scatter checks throughout the application.

Is there a standard way solve this type of problem?

[Mark C. Stock]

"Agoston Bejo" <gu***@freemail .hu> wrote in message
news:cj******** **@news.caesar. elte.hu...
| Hi, I'm having trouble with implementing some constraints on the database
| level. An example:
|
| --Table A(AID, BID ref. B.BID, ATXT)
| --Table B(BID, CID ref. C.CID)
| --Table C(CID)
|
| upon insertion into or updating in A I would like to force that ATXT is
| unique with respect to CID, i.e.
|
| SELECT COUNT(*) FROM A,B,C
| WHERE A.BID = B.BID
| AND B.CID = CID
| AND CID = fn_get_cid_for_ bid(:new.BID)
| AND A.ATXT = :new.ATXT
| AND A.AID <> :new.AID
|
| should be 0.
|
| This I cannot force with a check constraint since it is not allowed to
| contain subqueries.
| If I try to write a trigger that checks the above condition and raises an
| application error, then I always stumble upon the "table is mutating,
| trigger/function may not see it" -type error, since it involves a select
on
| the table that is being changed at the time.
|
| However, it would be better to implement such a constraint on the database
| level, rather than scatter checks throughout the application.
|
| Is there a standard way solve this type of problem?
|
|
|

hopefully i'm understanding the problem correctly....

there's no standard way, since your uniqueness constraint is based on
multiple tables (the way you have it currently designed)

however, if A.TXT is NOT NULL, then you could denormalize the table
implementation and include CID in A and put a unique constraint on (A.CID,
A.TXT). if A.TXT is NULL-able, you may want to denormalize the table
implementation and have a table that includes just the PK of A (AID?), CID,
and TXT, storing actual TXT entries out-of-line from table A, so that a
unique constraint can be put on CID and TXT in that table. the reason
NULL/NOT NULL comes into play is that oracle would not prevent multiple NULL
values in a one-column unique index, but would prevent multiple TXT nulls in
this case, since the CID value would be repeated

++ mcs

[wario]

--Table A(AID, BID ref. B.BID, CID ref. C.CID, ATXT)
--Table B(BID, CID ref. C.CID)
--Table C(CID)

1. Add CID key to table A.
2. Create unique index on CID and ATXT.

Wario

[Mark D Powell]

"Agoston Bejo" <gu***@freemail .hu> wrote in message news:<cj******* ***@news.caesar .elte.hu>...

Hi, I'm having trouble with implementing some constraints on the database
level. An example:

--Table A(AID, BID ref. B.BID, ATXT)
--Table B(BID, CID ref. C.CID)
--Table C(CID)

upon insertion into or updating in A I would like to force that ATXT is
unique with respect to CID, i.e.

SELECT COUNT(*) FROM A,B,C
WHERE A.BID = B.BID
AND B.CID = CID
AND CID = fn_get_cid_for_ bid(:new.BID)
AND A.ATXT = :new.ATXT
AND A.AID <> :new.AID

should be 0.

This I cannot force with a check constraint since it is not allowed to
contain subqueries.
If I try to write a trigger that checks the above condition and raises an
application error, then I always stumble upon the "table is mutating,
trigger/function may not see it" -type error, since it involves a select on
the table that is being changed at the time.

However, it would be better to implement such a constraint on the database
level, rather than scatter checks throughout the application.

Is there a standard way solve this type of problem?

The fact that the ATXT column of A needs to be unique in relation to
the CID value which does not appear in A indicates a relational design
flaw in your tables.

Without changing the table design there are several options:
1- Perform the inserts/update via stored code that performs the
validation up front avoiding the mutating table error

2- substitute a view for the table and use instead of triggers to
perform the validation and redirect the DML

3- Use a combination of before and after, statement and row level
triggers to work around the mutating table error. There are notes on
this technique on metalink, but I have never managed to use the
technique successfully to allow us to do what we needed in cases
similar to what you want to do.

HTH -- Mark D Powell --

[Agoston Bejo]

I would like to do this so that the structure of the tables remain the same.
(Since in the real-life analogue of this example it is important that the
structures reflect the real-life concepts.)

Anyway, the question is rather about the implementation of more complicated
constraints on tables than this specific example (which actually led me to
pose this question in the newsgroup).
"wario" <wa********@ins ightbb.com> wrote in message
news:96******** *************** *@posting.googl e.com...

--Table A(AID, BID ref. B.BID, CID ref. C.CID, ATXT)
--Table B(BID, CID ref. C.CID)
--Table C(CID)

1. Add CID key to table A.
2. Create unique index on CID and ATXT.

Wario

[Mark C. Stock]

"Agoston Bejo" <gu***@freemail .hu> wrote in message
news:cj******** **@news.caesar. elte.hu...
| I would like to do this so that the structure of the tables remain the
same.
| (Since in the real-life analogue of this example it is important that the
| structures reflect the real-life concepts.)
|
| Anyway, the question is rather about the implementation of more
complicated
| constraints on tables than this specific example (which actually led me to
| pose this question in the newsgroup).
|
|
| "wario" <wa********@ins ightbb.com> wrote in message
| news:96******** *************** *@posting.googl e.com...
| > --Table A(AID, BID ref. B.BID, CID ref. C.CID, ATXT)
| > --Table B(BID, CID ref. C.CID)
| > --Table C(CID)
| >
| > 1. Add CID key to table A.
| > 2. Create unique index on CID and ATXT.
| >
| > Wario
|
|

Typically, the conceptual data model should accurately reflect the business
reality -- but the actual table structure that implements the model will
usually be compromised (denormalized) to accommodate technology

keep in mind that if these are dependent tables, the natural key structure
would be:

C
CID
PK (CID )

B
CID
BID
FK(CID) ref C
PK(CID, BID)

A
CID
BID
AID
TXT
FK(CID, BID) ref B
PK(CID, BID, AID)

which then give you the option of adding the UK to table A -- but again, it
depends on factors that you've not yet stated

++ mcs

[Ed prochak]

"Agoston Bejo" <gu***@freemail .hu> wrote in message news:<cj******* ***@news.caesar .elte.hu>...

I would like to do this so that the structure of the tables remain the same.
(Since in the real-life analogue of this example it is important that the
structures reflect the real-life concepts.)

Anyway, the question is rather about the implementation of more complicated
constraints on tables than this specific example (which actually led me to
pose this question in the newsgroup).
"wario" <wa********@ins ightbb.com> wrote in message
news:96******** *************** *@posting.googl e.com...

--Table A(AID, BID ref. B.BID, CID ref. C.CID, ATXT)
--Table B(BID, CID ref. C.CID)
--Table C(CID)

1. Add CID key to table A.
2. Create unique index on CID and ATXT.

Wario

More complicated constraints require more complicated datamodels.
Why do you fear adding columns to tables when it allows you to better
model the "real-life concepts"?

Sounds like a meta constraint that is holding you back.
("We can not change the existing database structure since it is
supplied by an outside vendor.") Layering a kludge on top will never
be as good as making the changes needed in the datamodel.

Good luck.
Ed

[Noons]

Ma*********@eds .com (Mark D Powell) wrote in message news:<26******* *************** ****@posting.go ogle.com>...

The fact that the ATXT column of A needs to be unique in relation to
the CID value which does not appear in A indicates a relational design
flaw in your tables.
Bingo. In one.
Without changing the table design there are several options:
1- Perform the inserts/update via stored code that performs the
validation up front avoiding the mutating table error
This might have problems with apps that enforce "no changes
anywhere or else...".

2- substitute a view for the table and use instead of triggers to
perform the validation and redirect the DML
I've used this technique to implement complex relationships
- to do with subtyping and complex M-M - and even complete
new schemas, without having to change any original app code.
It works like a charm, is fast and is probably the most
transparent way of achieving this. Perfect solution IMHO.

3- Use a combination of before and after, statement and row level
triggers to work around the mutating table error. There are notes on
this technique on metalink, but I have never managed to use the
technique successfully to allow us to do what we needed in cases
similar to what you want to do.

Too much trouble. The instead of trigger with a view is perfect
for this.

I like Tom Kite's idea of a FBI, as proposed by HB. But I'm not
sure it won't introduce other problems. IIRC, Tom introduced
that technique at a time when instead of triggers were not yet
available. He probably would have used the triggers nowadays.

[Holger Baer]

Noons wrote:
[...]

Too much trouble. The instead of trigger with a view is perfect
for this.

I like Tom Kite's idea of a FBI, as proposed by HB. But I'm not
sure it won't introduce other problems. IIRC, Tom introduced
that technique at a time when instead of triggers were not yet
available. He probably would have used the triggers nowadays.

I'm not sure if the FBI solution introduces other problems, but
that's a different question.

However I'm sure instead of trigger where available in 8.0, whereas
FBI was introduced in 8i. So I'm not sure about the conclusion that
Tom wouldn't use this nowadays. What do we say in cases like this?
It depends....

Cheers, Holger

[Noons]

Holger Baer <ho*********@sc ience-computing.de> wrote in message news:<cj******* ***@news.BelWue .DE>...

However I'm sure instead of trigger where available in 8.0, whereas

I don't think so.