<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.
midrange.com
