RE: AW: Uniquely identifying a record in SQL without a unique key?

<snip>

At the end, though, the unique key concept got tricky when you wanted
historical information. Changing a part number today caused the past to be
changed. Database time travel!!!

</snip>



Unless you build in the temporal logic to support archival info. Of course,
you've just made things exponentially more complex.







-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Joe Pluta
Sent: Sunday, December 30, 2012 6:13 PM
To: Midrange Systems Technical Discussion
Subject: Re: AW: Uniquely identifying a record in SQL without a unique key?



On 12/30/2012 3:54 PM, <mailto:rob@xxxxxxxxx> rob@xxxxxxxxx wrote:

Occasionally this debate rages. From those who say that a transaction

log that logs with a simple timestamp, which may not be unique, is ok

and doesn't need a unique key to those who say even that needs a

unique key. I can see both sides of the argument. Hey, even IBM's

journals have a transaction number that is unique. However, some may

be concerned about the disk space used, etc. Doesn't take much to

generate a unique key.

Rob Berendt

The bigger debate in my mind is whether you should ONLY use a unique
generated key (as opposed to a "natural" key like customer number or order
number and line). This is a really interesting point and leads to some
wickedly interesting design decisions (if you're into that sort of thing).



I'm old school and I still tend towards unique keys, but I designed an
entire system based on unique generated keys and it had some powerful
features (like the ability to change a part number on the fly by updating
one record - every reference in every other record in the system stayed
unchanged).



At the end, though, the unique key concept got tricky when you wanted
historical information. Changing a part number today caused the past to be
changed. Database time travel!!!



Joe

--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: <mailto:MIDRANGE-L@xxxxxxxxxxxx>
MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options,

visit: <http://lists.midrange.com/mailman/listinfo/midrange-l>
http://lists.midrange.com/mailman/listinfo/midrange-l

or email: <mailto:MIDRANGE-L-request@xxxxxxxxxxxx>
MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a moment to
review the archives at <http://archive.midrange.com/midrange-l>
http://archive.midrange.com/midrange-l.