---------- Forwarded message ---------- Date: Mon, 19 Mar 2001 18:29:42 -0800 (PST) To: Rodd Holman <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
