Re: FK Constraints (fwd)

• Forwarded message ---------- Date: Mon, 19 Mar 2001 18:29:42 -0800 (PST) To: Rodd Holman <rodney.holman_at_lodgenet.com>

Rodd,

I understand completely. Third party apps often do their best to complicate a DBA's life.

Sorry for jumping in with both feet. :)

Jared

On Mon, 19 Mar 2001, Rodd Holman wrote:

> Jared and Jaques,
> I agree with you completely. RI should always be enforced at the DB level.
> I was just sharing my experience with a couple of 3rd party sotfware vendors
> that wouldn't allow me to put the constraints in the DB. In fact one of them
> had a lookup table hardcoded into the app interface. If you tried to enforce
> RI in the DB it would fail looking for parents on one of the child tables to
> this hardcoded table. (To stop any disparging of my credibility I had NO say
> in the purchasing of this RI nightmare. I was "gifted" with the
> "opportunity to excel" when the !@#$%& that stuck us with the app quit the
> company.) Their sole reason for the approach (valid or not) was db
> portability. Sadly small software shops crop up to fill niche needs and do
> not necessarily employ people who understand the inner workings of RDBMS's.
> They know how to make their cute forms and flashy reports using some wizbang
> dev tool and totally ignore the fact that a real foundation is need for
> proper functionality.
>
> On Monday 19 March 2001 15:21, you wrote:
> > I'll have to disagree with this. I've seen to many
> > programs break when the constraints were enabled.
> >
> > Developers generally don't have a clue how to maintain
> > integrity in the application data. This is not to impugn
> > all developers, just about 90% of them.
> >
> > The database knows how to enforce integrity, developers don't.
> >
> > As a DBA I insist on RI in the database.
> >
> > When there is no RI in the database, DBA's are constantly
> > being called for 'database problems' when the problem is
> > actually in the data, which is not our responsibility.
> >
> >
> > The DBA spends much time proving the source of the problem
> > since the developer is unable to.
> >
> > More fodder for duhveloper.com.
> >
> > Jared
> >

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: 
  INET: jkstill_at_cybcon.com

Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).