If you really want to be sure you never need to change a primary key make the primary key an auto-increment field and never use it for anything else. You would think something like an organizational assigned employee ID would never change but, guess what, they do.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Murphy, Mark
Sent: Tuesday, March 11, 2008 11:12 AM
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 )
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.
--
Walden H Leverich III
Tech Software
(516) 627-3800 x3051
WaldenL@xxxxxxxxxxxxxxx
http://www.TechSoftInc.com
Quiquid latine dictum sit altum viditur.
(Whatever is said in Latin seems profound.)
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at
http://archive.midrange.com/midrange-l.
midrange.com
