lists@mgreg.com kirjoitti:
Yes, I do have access to it. I've actually run into another problem
related to TIMESTAMPs though. Sometimes multiple rows get logged
"simultaneously" and tables with existing TIMESTAMP fields will post
repeat results (and I really don't want it to prevent a new post simply
because of the same TIMESTAMP). So timestamps in general might not be
the best. But that leads me to a couple of other questions:
TIMESTAMPs are not sufficient as IDs. Within a transaction the result of the
first call to any datetime function is cached and used in all subsequent calls,
i.e. all inserts/updates get exactly same timestamp. That's actually useful.
2) Is there any way to create a unique row identifier such that even
when the DB is backed up and flushed, it will not reuse them? For
example, if I back up rows 1-1000 and wipe the table, can I keep going
with 1001?
There are different ways to have a generator (generates unique numbers, usually
1,2,3...) associated with a table. MS SQL have tablewise generators and you can
easily set up one and modify it with the visual tools that come out-of-the-box.
Contrary to almost all database textbook examples, it isn't necessary a good
idea to have any business meaning in your (primary) keys. E.g. you might think
that an invoice number which is unique would make good primary key, but what
happens when a user cancels writing out an invoice (have you forfeited a number
and they should be continuous for bookkeeping purposes?) or the format changes
from a purely numeric to alphanumeric?
HTH,
Metsis
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives:
<http://support.realsoftware.com/listarchives/lists.html>
|