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

Walden H. Leverich wrote:

I've not done the research, but given that you most likely have an index
on this non-unique key anyway, wouldn't the added overhead for unique be
trivial. You're already maintaining the index, all you're adding is a
statement that says "if there's already a row in this index with this
key, throw". You had to find the right point in the index to insert the
non-unique key, so the page is already in memory.

I won't argue the technical details of the concept. I can only offer the empirical results: a non-unique keyed physical file takes approximately 15% the time that a unique keyed physical takes to insert a row.

However, for some reason adding a record to a separate logical file takes just as long whether the key is unique or not, so the empirical evidence is somewhat ambiguous. My position: if testing indicates there is no additional overhead (and by that, I mean a statistically insignificant difference on the order of a couple of percentage points) for adding a unique primary key, then I see no reason not to do it, especially considering the other real and potential benefits.

As always, I'm not for or against any technology for its own sake. I'm just against uninformed decisions.

Joe