Path: news.easynews.com!newsfeed1.easynews.com!easynews.com!easynews!news-feed01.roc.ny.frontiernet.net!chi1.webusenet.com!news.webusenet.com!pd2nf1so.cg.shawcable.net!residential.shaw.ca!feed.cgocable.net!newsfeed.torontointernetxchange.net!radon.golden.net!mantis.golden.net!not-for-mail From: "Bob Badour" Newsgroups: comp.databases.theory References: <5606b639.0304072055.29001bfe@posting.google.com> <6dae7e65.0304081929.34e4f8b2@posting.google.com> <5606b639.0304090641.2282467f@posting.google.com> Subject: Re: FK -> non PK - bad design? Lines: 33 X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Message-ID: Date: Fri, 11 Apr 2003 15:46:24 -0400 NNTP-Posting-Host: 207.35.144.146 X-Complaints-To: abuse@golden.net X-Trace: mantis.golden.net 1050094623 207.35.144.146 (Fri, 11 Apr 2003 16:57:03 EDT) NNTP-Posting-Date: Fri, 11 Apr 2003 16:57:03 EDT Organization: Golden Triangle On Line Inc. Xref: newsfeed1.easynews.com comp.databases.theory:25823 X-Received-Date: Fri, 11 Apr 2003 13:21:20 MST (news.easynews.com) "Mike" wrote in message news:a90c0da6.0304111119.2456eae9@posting.google.com... > Bernard Peek wrote in message news:... > > In message <5606b639.0304090641.2282467f@posting.google.com>, OtisUsenet > > writes > > > > > >I wanted to have a database-generated ID for each row just for sanity, > > >and because an Oracle DBA once told me it is always good to have a > > >db-generated id/PK in each table. > > > > This issue crops up here about once a month but I don't recall anyone > > saying that they did it for reasons of sanity. > > > > The brief version of the argument against using a system generated > > numeric and a separate text field is that you need to have a system to > > keep the two synchronised. That's more work and more error-prone than > > just using your Type field as a PK. > > > > Sometimes there are good reasons to choose a system generated ID but I'd > > recommend that you avoid them if you have a real key available in the > > data. > > Bernard, seems to me that just the fact that users may want to change > the name of a service plan is reason enough for a system generated > ID/PK. The original candidate key was not a name. It was an integer called 'type'. Unless users change the integers representing 'type' frequently, there is probably no reason to add a redundant integer key and thereby force users into unecessary joins.