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

"Marshall" <marshall.spight_at_gmail.com> wrote in message news:1174488227.987772.200770_at_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.
>

If you want to find out more about the use of such a type, lookup "synonym problem" and "homonym problem". Many types (or domains) that have been mismanaged by the user community suffer from one or both of these problems. If a surrogate type does nothing more than obviate these two problems, that's enough value to justify the upkeep.

One of the resons for hiding the surrogate from the user community is that they will, willy nilly, begin to use the surrogate for purposes beyond its original scope. In so doing, they will inevitably generate a synonym problem and/or a homonym problem. These problems will then propagate back into the database, or at least be perceived as having propagated back into the database.

This can undermine the credibility of the database, even if the data is still good. If you manage a database as a resource, you ignore this at your peril.

Hope this helps. Received on Thu Mar 22 2007 - 15:42:27 CET