Re: General question about fk constraints ... thank you !

From: Jan Gelbrich <j_gelbrich_at_westfalen-blatt.de>
Date: Mon, 10 Feb 2003 16:29:05 +0100
Message-ID: <b28giv$19bgqq$1@ID-152732.news.dfncis.de>

Thank You, Niall, for your response !

"Niall Litchfield" <n-litchfield_at_audit-commission.gov.uk> schrieb im Newsbeitrag news:3e47c303$0$22722$ed9e5944_at_reading.news.pipex.net...
> "Jan Gelbrich" <j_gelbrich_at_westfalen-blatt.de> wrote in message
> news:b27ql8$1a92b9$1_at_ID-152732.news.dfncis.de...
> > ... that is: about the drive of many software vendors to *avoid* them
...
> >
> > Hello !
> >
> > Just as a matter of interest, I would like to know *why* are so many
data
> > models implemented out there
> > are neglecting fk constraints to a degree that it makes me almost mad -
> > sorry ...
> >
> > When I was trained in ER design 1 and 1/2 year ago,
> > we were told never to sacrifice fk constraints for the douptful sake
> > of performance,
> > and we set up easy-to-read ERMs with countable table numbers and so on
...
> >
> > Now, on my working place I see (and from many others I hear) that it
seems
> > very common
> > *not* to use constraints, just for the sake of performance - all the
guys
> > around me say that, and they are
> > just asking "R U kidding ?! *Why* for *** sake do You wanna use
> constraints
> > ?! *You* as dba shoulda known better ... "
> > which makes me almost speechless for a moment 8|

>

> Any production DBA who thinks that performance is more important than data
> integrity has a rather large problem, IMO. FWIW I don't believe that the
> true reason for this trend has anything to do with performance, but does
> have everything to do with speed of development. If you can cut out the
> constraint definitions, logical design and correct transaction definitions
> from your app you can probably develop it in half the time.
>
> RAD when it means Rapid Application Development is good news, Rapid
Aircraft
> Development seems not to be an acronym - I wonder why.

So at least I am not the only one ...

I did not know *this* interpretation of RAD ... >D

That made sense to me.

Jan=) Received on Mon Feb 10 2003 - 09:29:05 CST