the DBA is not responsible for the data?? Could you PLEASE come to my office
and explain that (I'll bring the heavy club) to my developers, users and
management?
They seem to believe that my primary function is to dig information out of
the database for them. Backup and recovery? Capacity planning? Why on earth
would I want to do THAT?
>From: [EMAIL PROTECTED]
>Reply-To: [EMAIL PROTECTED]
>To: Multiple recipients of list ORACLE-L <[EMAIL PROTECTED]>
>Subject: RE: FK Constraints
>Date: Mon, 19 Mar 2001 13:20:34 -0800
>
>
>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
>
>On Mon, 19 Mar 2001, Holman, Rodney wrote:
>
> > You are running into a primary point of contention between many DBA's
>and
> > developers. Dev's don't like the use of PK/FK relationships within the
> > database because it is not always portable across multiple RDBMS's. By
> > making the app handle all the referential integrity issues they can say
> > "Yes, our system runs on Oracle, Sybase, Informix, MS SQL Server, or
>even
> > Access ...." All they need the RDBMS to do is store tables and indexes
>then.
> > Many third party apps use this approach. The problem is when their code
>is
> > correct and perfect, they are right. You don't NEED FK's. However I
>have
> > yet to run across any super human developer that codes everything
>perfectly.
> > What happens... you get duplicate key values and child tables filled
>with
> > orphans because somewhere in the code a restriction was missed. By
> > assigning these at the DB level you can forget about having to maintain
>it
> > in the app. The RDBMS does it for you. Push for RDBMS level control of
> > this. It will save you many headaches later over data corruption.
> >
> > Rodd Holman
> >
> > -----Original Message-----
> > Sent: Monday, March 19, 2001 12:05 PM
> > To: Multiple recipients of list ORACLE-L
> >
> >
> > Hi all:
> >
> > We have a situation where are no relationships are
> > defined at the database level. i.e no foreign keys
> > constraints have established at the Database. The
> > application is still at the Development Stage.
> >
> > Everything is controlled at the application level.
> >
> > I as the DBA appose this design for Data security and
> > also cannot reverse engineer from the tables into
> > Designer.
> >
> > Can you please share you pros / Cons.
> >
> > Thanks
> >
> >
> >
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get email at your own domain with Yahoo! Mail.
> > http://personal.mail.yahoo.com/
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: ramani akhil
> > 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).
> > --
> > Please see the official ORACLE-L FAQ: http://www.orafaq.com
> > --
> > Author: Holman, Rodney
> > 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).
> >
>
>--
>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).
_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Rachel Carmichael
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).
