From carmichr@hotmail.com Mon, 19 Mar 2001 16:29:37 -0800 From: "Rachel Carmichael" Date: Mon, 19 Mar 2001 16:29:37 -0800 Subject: RE: FK Constraints Message-ID: MIME-Version: 1.0 Content-Type: text/plain 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: jkstill@cybcon.com >Reply-To: ORACLE-L@fatcity.com >To: Multiple recipients of list ORACLE-L >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: srinirmala@yahoo.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@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). > > -- > > Please see the official ORACLE-L FAQ: http://www.orafaq.com > > -- > > Author: Holman, Rodney > > INET: rodney.holman@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@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). > > > >-- >Please see the official ORACLE-L FAQ: http://www.orafaq.com >-- >Author: > INET: jkstill@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@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). _________________________________________________________________ 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: carmichr@hotmail.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@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).