We've already been warned that we run the risk of being flamed over this
type of discussion!
But I think you need to read Ann Harrison's post and Helen Borrie's post
(both of 29 Aug) to put some perspective on what appears to be, for some, an
emotional subject.

The absence of "CONSTRAINTS" in the context of the backend does not
necessarily mean the absence of referential integrity. Goodness, we used not
to even have such a luxury as a constraint mechanism and we lived with what
means we had, to manage RI. And you are correct, the presence of these
constraints present significant issues when developing the structure of your
database. But there is also good reason to install the contraints before
distribution. The fact that the constraint is then operating within the
system context rather than the transactional context is a sound reason.

That said, it must also be warranted by such things as the installation
environment, the number of users, the types of third party tools, if any,
being used, and let's not forget the data... believe it or not there may be
some data stores which do not need constraint of this type. Data arguably
called "orphaned" under one regime, may not be orphaned at all under other
regimes.

There may also be good reason to match your system to a very (dare I say
even more) poorly written datastore which denies the use of contraints but
does offer RI where there is a reason for the presence of "orphans". If your
system want to deny the existence of orphans then contraints are necessary.
If your system utilises "orphans" as a special case, the constraints will
deny the use of this special case. And I imagine someone will argue that
it's against the law to use orphans as a special case. Or they will argue
that since orphans are a special case then it is not a case they would argue
for constraint anyway.

If you were designing and responsible for building the backend, while some
other "unknown" party was devoted to design and developing the client
application, there would be even more compelling argument for final
installation of contraints, especialy if the application were to be in high
use by people who are likely to find ways of "tinkering" over the data with
third party tools. Other people may also argue, though, that many client
application rules are installed simultaneous to the construction and
development of the backend by - you guessed it.. the same person. By the
time the client is completed, all necessary rules for maintaining integrity
may be quite sufficient.

Finally, I think the use of the term "triggers" thus far has really stood
for "things other than just FK Contraints imposed by IB/FB/Backend". It may
be misleading to continue using the term triggers to refer to all other
methods of ensuring RI because there are many. And all these methods or
tools are at your disposal and for you to use as you have legitimately
decide they are to be used.

Alan McDonald

-----Original Message-----
From: Theo Bebekis [mailto:teo@...]
Sent: Thursday, 29 August 2002 18:30
To: ib-support@yahoogroups.com
Subject: Re: [ib-support] Re: Helen: Low Selectivity Problem


Woody

> through deleting child records when a master record is deleted. I only

use

> PKs and not FKs and have had no speed problems to date nor any other for

Me (and I suspect many others) too...

> that matter. Lucky? Could be, but I find it far easier to change data
> structures, procedures, etc. without having to continually remove and
> replace constraints while developing. This process works best for me so

this

That's my primary reason for not using declarative referential integrity
(DRI).
It's a pain while developing...

There is a point that data is not sealed when the database with no DRI
is accessed using an external tool. That's true but it doesn't relate to
RI only.
Let's say I have a complex OID policy or whatever. Inserting/altering data
by using an external tool brakes my OID rules for sure. How do I solve the
problem? (rhetorical question)

The use of external tools should be restricted. Just for selecting; never
altering/inserting. I mean the end-users...

In any case this debate is very usefull to me and I believe to many
others.
So please, you experienced RDBMS users share your points,
arguments, thoughts with us and let this discussion go in depth

It might be useful also to set up a poll, say "Do you use declarative
referential integrity?"

Best regards
Theo

-----------------------------------
Theo Bebekis
Thessaloniki, Greece
bebekis@...
teo@...
-----------------------------------



Yahoo! Groups Sponsor
ADVERTISEMENT



To unsubscribe from this group, send an email to:
ib-support-unsubscribe@egroups.com



Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.



[Non-text portions of this message have been removed]