Thanks for all responses! I agree with most of you, and say that the RI is best maintened by Database ! Performance must be improved in other ways (indexes, hardware, etc)! ----- Original Message ----- From: "Jim C. Nasby" <jnasby@xxxxxxxxxxxxx> To: "Craig A. James" <cjames@xxxxxxxxxxxxxxxx> Cc: "PFC" <lists@xxxxxxxxxx>; "Michael Glaesemann" <grzm@xxxxxxxxxxxxx>; "Rodrigo Sakai" <rodrigo.sakai@xxxxxxxxxxxxxx>; <pgsql-performance@xxxxxxxxxxxxxx> Sent: Wednesday, April 12, 2006 5:59 PM Subject: Re: [PERFORM] FOREIGN KEYS vs PERFORMANCE > On Wed, Apr 12, 2006 at 10:36:28AM -0700, Craig A. James wrote: > > Jim C. Nasby wrote: > > >>1. You have only one application that modifies the data. (Otherwise, you > > >>have to duplicate the rules across many applications, leading to a > > >>code-maintenance nightmare). > > > > > >You forgot something: > > > > > >1a: You know that there will never, ever, ever, ever, be any other > > >application that wants to talk to the database. > > > > > >I know tons of people that get burned because they go with something > > >that's "good enough for now", and then regret that decision for years to > > >come. > > > > No, I don't agree with this. Too many people waste time designing for > > "what if..." scenarios that never happen. You don't want to be dumb and > > design something that locks out a foreseeable and likely future need, but > > referential integrity doesn't meet this criterion. There's nothing to keep > > you from changing from app-managed to database-managed referential > > integrity if your needs change. > > In this case your argument makes no sense, because you will spend far > more time re-creating RI capability inside an application than if you > just use what the database offers natively. > > It's certainly true that you don't want to over-engineer for no reason, > but many times choices are made to save a very small amount of time or > hassle up-front, and those choices become extremely painful later. > -- > Jim C. Nasby, Sr. Engineering Consultant jnasby@xxxxxxxxxxxxx > Pervasive Software http://pervasive.com work: 512-231-6117 > vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461 > > ---------------------------(end of broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@xxxxxxxxxxxxxx so that your > message can get through to the mailing list cleanly >
