Re: Negative Numbers in "Identity" or" Autonumber" fields
Date: Thu, 22 Mar 2007 16:14:01 GMT
Message-ID: <dXxMh.13672$PV3.140550_at_ursa-nb00s0.nbnet.nb.ca>
David Cressey wrote:
> "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.
I followed your recommendation, and I found nothing relevant to data management. I found something related to virtual memory under "synonym problem" and nothing even remotely relevant under "homonym problem".
Can you provide any more precise direction to what you suppose supports your position? Received on Thu Mar 22 2007 - 17:14:01 CET