Re: ID field as logical address

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.

>> 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.

>> 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.

[...]

>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.

-- 
Reinier