Re: General question about fk constraints ...

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

--
Niall Litchfield
Oracle DBA
Audit Commission UK