Re: FK Constraints

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

--
Rodd Holman
Oracle DBA
(605) 988-1373
rodney.holman_at_lodgenet.com
Comments made are my own opinions and views. They do not represent views,
policies, or procedures of LodgeNet Entertainment Corporation

-------------------------------------------------------

-- 
Rodd Holman
Oracle DBA
(605) 988-1373
rodney.holman_at_lodgenet.com
Comments made are my own opinions and views. They do not represent views, 
policies, or procedures of LodgeNet Entertainment Corporation


-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Rodd Holman
  INET: rodney.holman_at_lodgenet.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).