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...
[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.
* "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
This thread ...
RE: Why non-keyed PFs back then? Why today? ( was Re: Which of theSYSIBMtables/views show the row count for ), (continued)
This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact