Re: Negative Numbers in "Identity" or" Autonumber" fields

From: Marshall <marshall.spight_at_gmail.com>
Date: 21 Mar 2007 07:43:48 -0700
Message-ID: <1174488227.987772.200770@p15g2000hsd.googlegroups.com>

On Mar 21, 6:26 am, "David Cressey" <cresse..._at_verizon.net> wrote:

> However, the word "only" in your post means something like "less than"
> conveys no information.
> This is not the case for the numbers one takes for service at the deli
> counter. If they say "now serving 72" and my number is 73, that tells me
> something. Or am I misreading you.

[There were four posts asking me what I meant; I'll reply to this one.]

The idea is a type for which the only operator defined is '='. If we have two values of this type, we can tell whether they are the same, and that's all we can tell. Further we have a way to acquire a value of this type that has not been used in the current system state before.

I have run in to this construct a few times in the past, in papers on various topics, and it appears to be exactly what was being described in the quoted Codd paper.

It leaves me somewhat puzzled, because
it appears to have use but it doesn't appear to do anything. In the RM world it can function as a surrogate. I also run into this is security papers. "An unforgeable token" is what it is usually called in security land. I vaguely recall it had other uses but I don't offhand remember what they are.

One argument for its use as a surrogate key is that you don't want to inherit all the operators that come with a "real" type. It's not meaningful to say, add two primary keys. OTOH, so what? I've never run in to a problem that was caused by having an int surrogate, and on rare occasion I *have* found use for using avg() on one, believe it or not.

Anyway, I've mostly lost interest in that type, because I don't particularly see the need, and it's troubling theoretically, but I never really "shot it down" either.

Sorry to be somewhat vague.

Marshall Received on Wed Mar 21 2007 - 09:43:48 CDT