Re: 3NF question

>> I believe ID can be an acceptable attribute for an object, even if a
sequential identity scheme is deemed unsuitable. <<

Acording to ISO-11179 and basic data modeling, "id" is too vague to be a data element name and RDBMS does not have objects in it.

>> I don't believe that one should reject a sequential identity scheme
based soley upon a distaste for that which is proprietary (Yes, I enjoyed the BIBLE and I remember other good objections were also made). <<

Okay, if IT Standards and portability are not enough, then how about data integrity? Validation? Verification?

As part of my joke about the Hebrew numbers, I tell people that unlike IDENTITY, et al, you can verify it by geeeting an Ultra Orthodox rabbi who knows the Kabbala to read it to you.

>> It seems reasonable that one could have no requirement placed upon
ID generation other than that it occur quickly. <<

Well, if you don't care if your data is right, you can be VERY fast :) The answer is 42; what was the question? Who cares!

The "MAX(keycol) +1" trick is good, but you have to watch your isolation levels. The nice part is that you can add a check digit, too.

But the trouble with any of these auto-numberings is that they cannot be verified in reality. I add a row and it gets 12 as its generated pseudo-key; I drop the row; I insert the identical row back; it gets 13 as its generated pseudo-key. All references to 12 are screwed up beyond repair.

>> I can only think that some sordid bits of PL/SQL or Transact SQL
code
might be needed to perform several operations corresponding to ID generation, uniqueness verification and possible storage. <<

Set up the equivalent of a old manual "Forms Manager" which has the numbers to be used and which tracks the "who, what, where and when" as they are issued. The code is not bad at all, you do not have to use a sequential order, and the check digits can be as complex as you wish. The audit trail also makes the Trolls in Accounting happier. Received on Sun Jan 09 2005 - 16:20:59 CET