Re: ID field as logical address

"none (Reinier Post)" <rp_at_raampje.> wrote in message news:4a2d87a2$0$24900$703f8584_at_news.kpn.nl...
> Brian Selzer wrote:
>
>>"Bernard Peek" <bap_at_shrdlu.com> wrote
>
>>> Let's get metaphysical. There is an attribute of every unique object
>>> called "Identity." This is a non-numeric dimensionless constant. What
>>> makes this difficult to deal with is that there is no function that can
>>> be
>>> applied to {Identity} which returns a meaningful text string.
>
> Worse, such absolute identity cannot be observed at all.
> I don't think it really *is* an attribute.
>
> What *does* exist is *relative* identity: an attribute explicitly assigned
> to objects to distinguish them by some mechanism that guarantees that
> the assignment is unique - within the given context and under certain
> assumptions.
>
> Brian Selzer adds:
>
>>In fact, identity is a relation. The word you're looking for is
>>haecceity,
>>"thisness." The haecceity of something is essentially just that which
>>distinguishes it from everything else. Haecceity can be embodied by a
>>rigid
>>designator, or a rigid definite description, but it is in fact a separate
>>property that is dependent upon neither. What can be said about haecceity
>>is that everything that can be has one--one that is different than that of
>>every other thing that can be.
>
> But what is the nature of this relation? Is it something we observe,
> or something we mentally construct to simplify talking about the world?
> I think it's the latter.

Does it matter?

>>> We therefore choose a range of surrogate keys which can be manipulated
>>> as
>>> text strings and to a greater or lesser extent map 1:1 to the Identity
>>> value.
>>
>>Not exactly. We include enough of the properties of each in the set of
>>things being represented in order to just be able to distinguish one from
>>another at any given point in time, which is all that is required in order
>>to represent them in a relation or reason about them using first order
>>predicate logic. Surrogates need only be introduced when some of those
>>properties are not relevant to the problem at hand.
>
> Surrogates need to be introduced when no set of natural properties is
> sufficiently distinctive.

Though there are things that do not occur in nature, due to Leibniz Law, everything that does has a sufficiently distinctive set of natural properties.

>>> In some cases we have natural keys where the mapping is enforced by the
>>> laws of physics. In other cases we issue an invented value to identify
>>> an
>>> object, and we attempt to maintain the 1:1 mapping by processes that
>>> take
>>> place outside the database. So we issue a National Insurance number and
>>> tell the person it identifies to remember on pain of dire consequences.
>>>
>>> In every case that I can think of the mapping is maintained by processes
>>> that are outside the database and outside the relational model. The
>>> relational model takes it as axiomatic that this mapping is somehow
>>> maintained. It does not deal with how it is maintained.
>
> I would consider autonumbering of autonumbered keys to take place
> within the database, but an external process can be used as well.
>
>>I have to disagree. Codd anticipated the need for key updates when he
>>introduced the Relational Model to the world. He wrote:
>
> [...]
>
>> There are, of course, several possible ways in which a
>> system can detect inconsistencies and respond to them.
>> In one approach the system checks for possible inconsist-
>> ency whenever an insertion, deletion, or key update occurs.
>> --page 387.
>
> Nice catch.
>
>>If any prime attribute can be the target of an update, then, obviously,
>>multiple instances of a key can map to the same thing but only at
>>different
>>times, and a single instance of a key can map to different things but only
>>at different times.
>
> Yes, and this makes it hard to specify transition constraints.
> It's a little kludgy to disable them whenever key updates are made.

It should be possible to specify all transition constraints declaratively, even for updates that target prime attributes. It's more than a kludge to disable them, it's an anathema.

>
> [...]
>
>>I don't think they are pathological conditions. The real pathology is
>>that
>>there seems to be a pervading implication in the posts here on CDT that
>>every relation should if at all possible have just one unary key and that
>>there is even always a choice of a key, when there are in fact a myriad of
> [...]
>
> But don't you agree that a relation with a mutable key is really
> impractical? It truly makes it more difficult to maintain a correct
> relationship between database content and the state of affairs outside.
> There is a reason people use surrogates whenever they get the chance.
>

I really don't. Maintaining the relationship during a transition from one state to another is not a problem, provided delete, insert and update are primitive operators and not just shortcuts for assignment, and if there is a need to maintain the history of something, then the instance of the key at the time it first appeared can be used as permanent identification.

> --
> Reinier
Received on Tue Jun 09 2009 - 03:14:13 CEST