RE: Why non-keyed PFs back then? Why today? ( was Re: Which ofthe SYSIBMtables/views show the row count for )

I have always heard that a good primary key is a property of the object that doesn't change. So by
definition, you don't want to change the primary key. However, I was at a shop where the designer
didn't hold to that philosophy, and chose a primary key for a locator system based on the location.
It was a disaster because the primary key of records were constantly changing, and it was impossible
to track items through the system because there was no stable primary key.

-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Evan
Harris
Sent: Monday, March 10, 2008 11:24 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Why non-keyed PFs back then? Why today? ( was Re: Which ofthe SYSIBMtables/views show the
row count for )

Hi Walden

I don't disagree at all with your point of view, bit I read Booth's post to
mean that the key wasn't defined on the physical because the key field could
not be changed, not because the table didn't actually have one.

Now, I know you're going to say "what reason could you have for wanting to
change a primary key" - and I can't think of a good one right off the top of
my head - but I can remember wanting to do this on a few occasions in the
distant past, mostly when patching data.

I'm not advocating that as good practise, I'm just saying I can remember
wanting to do it...

Regards
Evan Harris


-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Walden H. Leverich
Sent: Tuesday, 11 March 2008 12:38 p.m.
To: Midrange Systems Technical Discussion
Subject: RE: Why non-keyed PFs back then? Why today? ( was Re: Which of the
SYSIBMtables/views show the row count for )

I can't think of a reason I'd design a table today (on any platform)
that didn't include a primary key. If there is no pure business key,
make a surrogate key of an integer. Most DB modeling apps will want to
see a primary key when displaying relationships, and most FK
relationships will be to the primary key (can you even do non-PK
relationships, not sure).

At any rate, I'd be shocked if someone could come up with a good reason*
to define a table today w/out a primary key.

-Walden

* "Good reason" does not include: Because that's how we do it, or
Because our old-timers wouldn't understand it. I mean a good real
technical reason.