Re: Serializability of Transactions and Automatic (Number) Generators
Date: Sun, 05 Dec 2004 11:08:52 +0000
Message-ID: <41b2ec45$0$9341$ed2619ec_at_ptn-nntp-reader02.plus.net>
pc wrote:
>> Wouldn't any abstract identifier stored on a computer end up with a >> default ordering in the minds of users though? Because underneath, it >> will be always be stored as numbers (e.g. the ASCII codes).
>
> i probably shouldn't try to answer this (not qualified!) but i can't
> resist: I suspect that 'in the minds' depends on one's culture. Not
> that i know enough about other cultures to say otherwise, but i wouldn't
> assume this.
I guess it would depend on culture but I don't think that affects the main argument. For example, consider the colours. Do they have an order? Maybe by the wavelength of light that produces that colour? But if they are written down to be stored in a database, maybe alphabetically (which depends on the language used of course). Or maybe as a RBG 6-digit hexadecimal number like HTML uses.
>> How would you have get a totally abstract identifier that has no >> ordering baggage coming along with it?
>
> i presume that you are talking about ensuring that the RM has no
> dependency on ordering. i have never seen any real rationale for this
> restriction (even though i agree with it). i have always assumed that
> Codd was trying to avoid baggage of another kind - namely IMS's where a
> child segment that followed (in storage or in a navigation path) a
> certain parent segment was inferred to be that parent's child!
I think that rather than being about the RM in general, it's about ensuring that a particular column in a particular database has no ordering if no such requirement exists.
I think the idea is that if you want an artificial key for a table, your only requirement is that it is unique. So a set which also has an ordering defined on it, and maybe some addition and multiplication as well, is overkill for this situation - you want a set whch has exactly the properties you require, and no more.
> maybe he had in mind avoiding effects of collation too, but if he did,
> i'd say that the behaviour of domains (ie. types) very much overrides
> such effects, since it is a psychological choice (from the DB's
> perspective) how we choose to define the operators on a domain (eg. we
> might choose to not define a 'less than' operator).
Good point - so you'd have a domain similar to the integers, but without any operators defined on it apart from the equality operator? Then although the users would attach a psychological ordering to the domain, they wouldn't be able to use that, because no operators exist to take advantage of it.
> personally, i still don't see the connection between the use of integers
> to make a definition of RM and the RM itself depending on any internal
> ordering. for that matter, as somebody else on this thread pointed out,
> i don't even see that the definition (as opposed to the RM itself) is
> dependent on ordering - you could reverse the ordering of the integers
> and the definition would define the same thing. The sequence of
> integers in the definition seems to be merely a short-cut to
> avoid enumeration.
I think it's more of a modelling question than about the RM itself. So an auto-generated key should use this new "unique identifier" domain instead of an integer domain, so questions of "gaps" in the sequence would be meaningless. As would calling it a "sequence" in fact.
Paul. Received on Sun Dec 05 2004 - 12:08:52 CET