Path: news.f.de.plusline.net!news-fra1.dfn.de!news.tele.dk!feed118.news.tele.dk!postnews.google.com!j4g2000prf.googlegroups.com!not-for-mail From: joel garry Newsgroups: comp.databases.oracle.server,comp.databases.oracle.misc Subject: Re: not using foreign keys? Date: Wed, 06 Jun 2007 16:11:10 -0700 Organization: http://groups.google.com Lines: 46 Message-ID: <1181171470.572443.103730@j4g2000prf.googlegroups.com> References: <1180979621.128496.281540@n4g2000hsb.googlegroups.com> <46644eb3$0$16320$88260bb3@free.teranews.com> <1181141106.374929@bubbleator.drizzle.com> <136eba3ge4vpk1e@corp.supernews.com> NNTP-Posting-Host: 75.49.200.201 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Trace: posting.google.com 1181171471 14110 127.0.0.1 (6 Jun 2007 23:11:11 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 6 Jun 2007 23:11:11 +0000 (UTC) In-Reply-To: <136eba3ge4vpk1e@corp.supernews.com> User-Agent: G2/1.0 X-HTTP-UserAgent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1),gzip(gfe),gzip(gfe) X-HTTP-Via: 1.0 ISA2K4-OC1 Complaints-To: groups-abuse@google.com Injection-Info: j4g2000prf.googlegroups.com; posting-host=75.49.200.201; posting-account=YRNZ5wwAAAAg-yYjMFwy3FyWUbPiwNdq Xref: news.f.de.plusline.net comp.databases.oracle.server:199061 comp.databases.oracle.misc:79876 On Jun 6, 2:55 pm, Walt wrote: > DA Morgan wrote: > > Brian Peasland wrote: > > >> A worse approach would be to let the application handle the > >> referential integrity. But don't get me started on that.... > > > What we somehow need to educate these front-end developers about is that > > front-ends are technically incapable of enforcing referential integrity. > > > They give the appearance of doing so but actually do not and can not. > > No front-end designable is capable of keeping someone accessing the > > data with any other tool from destroying it be that batch loads with > > SQL*Loader, DBAs with SQL*Plus, or a host of tools that use ODBC or JDBC. > > Well said. > > I think in this case we're looking at a data designer who is *planning* > on wanking the data with one of those tools. Iron clad data integrity > rules make for a "closed system" that you can't bend to your whim using > sql*plus or your chainsaw of choice. > > What's needed here is a DBA who understands the value of data, and also > understands that he shouldn't be allowed to break the rules of data > integrity any more than the lowly applications programmers. > > //Walt Playing devil's advocate for a moment, I see that there is some relatively low level of rule where it becomes simply beyond the capabilities of the database to constrain. So, wouldn't there be some design value to not having two completely different constraint mechanisms (one in the database that needs to be undone at times anyways, and the one that can handle more complex rules)? (Lest anyone misunderstand, I'm with the advocates of "as much in the db as possible." However, not 5 minutes ago I was working on some ETL stuff that requires the same data to be viewed with both historical and current integrity constraints. Yes, it is wanked with sql*loader.) jg -- @home.com is bogus. Torture that data until it gives you what you want! Bwahahaha!