Re: time/date as key fields

... it depends, maybe for referential constraints, if there are database relations.
BTW: genUUID on AS/400 is only most likely unique!!! Best choice would be an identity column, if uniqueness is needed.

D*B

--------------------------------------------------
From: <rob@xxxxxxxxx>
Sent: Friday, November 19, 2010 2:33 PM
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Subject: Re: time/date as key fields

Do you really need uniqueness in a transaction history field? Let's say
you are Walmart and you had two purchases of aspirin on 11/19/2010 at
11:10:25. So your item history file has two records at that same time.
Who cares? Now, there may be something in there that ties back to
transaction id so that you could tie it back to a register receipt or
online purchase. There's nothing actually to say that the same register
pumped through two bottles in the same second, and still be two records in
the item transaction history file.

Normally when you purge a transaction history file it's by a date range so
you aren't inhibited by lack of uniqueness. Now if your system is fubared
and you're goal is to remove a series of double entries from a programming
bug then that's more of a freak and stupid errors should make the
programmer work harder to back them out.

But, in summary, does a transaction history file really need a unique key?

If you do, then use UUID or GUID, an "SQL sequence" or whatever. STW for
more info on those. And then use a unique key constraint.

Rob Berendt
--
Group Dekko
Dept 1600
Mail to: 2505 Dekko Drive
Garrett, IN 46738
Ship to: Dock 108
6928N 400E
Kendallville, IN 46755
http://www.dekko.com





From: <dieter.bender@xxxxxxxxxxxx>
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Date: 11/19/2010 06:20 AM
Subject: Re: time/date as key fields
Sent by: midrange-l-bounces@xxxxxxxxxxxx



...uniqueness is not guaranteed and the sequence might not be strict. A
transaction number could be addedd automatically and using a view it could

be unvisable to the application.

Dieter



--------------------------------------------------
From: "David FOXWELL" <David.FOXWELL@xxxxxxxxx>
Sent: Friday, November 19, 2010 10:21 AM
To: "Midrange Systems Technical Discussion" <midrange-l@xxxxxxxxxxxx>
Subject: time/date as key fields

Is there anything wrong in using date and time of creation fields

already

existing in a transaction table to keep track of transaction history or
would it be advisable to add a separate field transaction_number? The
latter means a lot more program changes.

Thanks

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