--- In ib-support@y..., "Theo Bebekis" <teo@e...> wrote:

> > 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

Guys, data storage and access model and model of functionality of
your application should be developed mainly by head, not by hands ;)
Spend some time to build for youself model of what you are starting to
develop and how it can progress in the future before you start
developing and need in metadata changes will be significantly reduced.
As it said in my lovest book on system analysis - first point of
investigation in any investigation should be investigation itself.

Inserting/altering data

> by using an external tool brakes my OID rules for sure. How do I

solve the

> problem? (rhetorical question)

Rhetorical answer: using RI ;) which add to properties of your
database ability to defend itself.

> So please, you experienced RDBMS users share your points,
> arguments, thoughts with us and let this discussion go in depth

The best argument is Ann's post in this thread. Let's say we have BI
trigger on detail table which check exictence of master record. Within
some transaction's context we make insert. Another transaction deleted
master record after our transaction's start. If our transaction is
snapshot, trigger never will see absence of master record even if it
commited. If it is read_commited, it will see delete only if at the
moment of check it is commited. We commit insert, another transaction
commit delete - voila, get inconsistent data.

> It might be useful also to set up a poll, say "Do you use

declarative referential integrity?"

I think developers of the complex databases for heavy multy-user
environment always use it. Developers of desktop applications can
ignore it nearly painless. Those in the middle make risky design if
they don't use RI, level of this risk is dependent on apllication
nature.
BTW, I can't say low selective FK have high influence on data
changing (except batch-type changes, of course). For select statements
we always can create proper general indices or force natural access in
statement itself. So, we really have another problem - optimizer, who
often is confused when he have a choice even of two indices to use the
best for this particular statement ;))

Best regards, Alexander V.Nevsky.