Quote: "Validating these rules in client applications is not the bulletproof
solution because people might be able to use a third party tool to insert,
delete or update data."
This is the only reason Claudio offers as to why clients are not a good way
to maintain RI.
"might" is a good choice of words here.... and in many cases the odds of a
"rogue" use of client tools is so small as not to even mention.
I don't necessarily argue against his assertions but since there are no laws
here other than what works and doesn't work with the DB engine ....e.g. the
non or wring use of SUSPEND or EXIT may result in erroneous selects, but the
non-use of FK constraints does not invalidate a database per se. I can and
have, gone thru my databases at times and applied constraints where they
apply. The performance has not suffered, and the data is no more valid (even
after several years) than it was before the contraints were present. What
does this say? And yet with the FK constraints in place, I have still
managed to manually destroy some sections of data during trials of client
upgrades, while still not colliding with an constraint exception...(thank
god for test databases).

Believe it not.. I do not modify my delphi application source to the
following:
Application.CreateForm(TMain, Main);
try
Application.Run;
except
.......
maybe I should

all good fun eh?
Alan
-----Original Message-----
From: Ales Kahanek [mailto:ales.kahanek@...]
Sent: Wednesday, 28 August 2002 21:04
To: 'ib-support@yahoogroups.com'
Subject: RE: [ib-support] Re: Helen: Low Selectivity Problem


The article from Claudio is on my opinion one big recommendation to use FK
constraints ...
Ales

> -----Original Message-----
> From: Frank Ingermann [mailto:frank@...]
> Sent: Tuesday, August 27, 2002 12:18 PM
> To: ib-support@yahoogroups.com
> Subject: Re: [ib-support] Re: Helen: Low Selectivity Problem
>
>
> Hi Ryan,
>
> Scronkey wrote:
> > --- In ib-support@y..., "Alan McDonald" <alan@m...> wrote:
> >
> >>I might jump in here...
> >>I do not use foreign keys at all in my databases!
> >>ooooh I hear frowns and tisk tisks here....
> >>but nonetheless, my triggers do all the work for me. They also
> >>provide a far more comfortable environment to develop in.
> >>
> >>Alan
> >>
> >
> >
> > Could you possibly point me to some info regarding triggers and RI?
> > I'm quite new to FB / triggers / sp's
> > I will research CREATE EXCEPTION like Helen suggested.
> >
> > Rgds,
> > -Ryan
>
> this might be something for you: Claudio V.'s article on
> "Declarative referential integrity v/s triggers"
> http://www.cvalde.com/document/declaRefIntegVsTrig.htm
>
> it explains some important issues to keep in mind when doing
> RI "by hand". what
> it doesn't have is example triggers - in case you get stuck,
> just keep asking :-)
>
> (i'm doing RI by hand because a) nothing ever gets deleted in
> my gdb and b) all
> relations/joins go via surrogate keys, so what's left of RI
> is so little that it
> is easier done with triggers *in my case*...)
>
> regards & hth,
> fingerman
> --
> --------------------------------------------------------------
> -----------
> when parsers parse, and compilers compile, then why don't
> objects object?
>
> fingerbirdy - fingerman's door to Firebird
> http://www.fingerbird.de
>
>
> ------------------------ Yahoo! Groups Sponsor
> ---------------------~-->
> 4 DVDs Free +s&p Join Now
> http://us.click.yahoo.com/pt6YBB/NXiEAA/mG3HAA/67folB/TM
> --------------------------------------------------------------
> -------~->
>
> To unsubscribe from this group, send an email to:
> ib-support-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to

http://docs.yahoo.com/info/terms/


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]