>> > Pish! There is no such thing as an 'essence'. See 'King Milindi's
>> > chariot' for a good explication.

>> >> and it's also possible for something to be identified by a property
>> >> that can change.

>> > Nope. Not if you want to compare it over time (which is what you are
>> > talking about). Then it's not an identifying property at all. And that
>> > sort of consideration should be occuring way before the RM is applied.

>> So, what you're saying is, "Never use natural keys."  Right?

> No.

>> >> For example, consider a line of people at the bank.  Both
>> >> Person and Position are identifying properties.  Assume that you're
>> >> third
>> >> in
>> >> line, so Person is you, and Position is 3.  When the guy at the head
>> >> of
>> >> the
>> >> line leaves, your Position changes to 2.  Now let's put that in the
>> >> context
>> >> of a database.  You have a relation with candidate keys Person and
>> >> Position.
>> >> So the current instance might look something like

>> >> {(Bob, 1), (Brian, 2), (You, 3)}.

>> >> The proposed instance would look something like

>> >> {(Brian, 1), (You, 2)}

>> >> Even though Position is a candidate key in each situation and
>> >> indirectly
>> >> identifies

>> > 'Indirect identity'? There is no such distinction to be made.

>> I didn't say indirect identity, I said indirectly identifies.  The
>> candidate
>> key value identifies a fact which in turn identifies a thing.  There is
>> indeed a distinction.

>> >> an entry in the queue, the value 2 from the current instance
>> >> identifies the tuple containing You in the proposed instance, not the
>> >> one
>> >> containing Brian.  This illustrates the difference in the frame of
>> >> reference
>> >> for a candidate key and that for an update, and Position is an example
>> >> of
>> >> an
>> >> identifying property that can change.

>> > Why not extend this? Perhaps brian changed his name to bob while he was
>> > waiting, and queueing positions are changed from numerical to
>> > alphabetical by the bank

>> > rv1: { (Brian, 2) }
>> > rv2: { (Bob, A) }

>> > ...and you want to automagically correlate these things? Rather than
>> > think in hindsight maybe the identifiers chosen for the entities
>> > concerned might have been a wee bit of a mistake? Does that not strike
>> > you as making more sense?

>> If a key can change, it will.  It doesn't matter how stable it is.
>> Choosing
>> a stable key only reduces the probability that a change will occur or
>> reduces the frequency of the changes.  It does not eliminate the
>> possibility.  Your example above supports my argument.  Imagine a very
>> large
>> database that is updated tens or hundreds of thousands of times a day.
>> Now
>> assume that the probability of a change ocurring is .01%.  This means
>> that
>> at least once a day there's a possibility of corrupting the database.
>> The
>> point, even if you can't see it, is that it is not a matter of choosing a
>> more stable key.  No update should *ever* be able to violate or
>> circumvent
>> the database predicate.  If an update *can* violate integrity rules, then
>> either the data model is broken or the implementation is broken.  If the
>> definition of the model cannot prevent it, then the model is broken.

> Yes, yes, I follow your logic, but it is still flawed: one attribute
> out there will be completely stable for your specific problem space, if
> you so desire to find it. That's the nature of identity and what allows
> you identification in the first place.

>> >> >>> >> > Maybe, but from a functional standpoint, that operator is
>> >> >>> >> > just a
>> >> >>> >> > function (e.g. "subtract $500 from X), in which the balance
>> >> >>> >> > is a
>> >> >>> >> > free
>> >> >>> >> > variable. Only in an imperative world does that involve
>> >> >>> >> > "knowing"
>> >> >>> >> > (referencing) the "previous" balance. Function application
>> >> >>> >> > means
>> >> >>> >> > there's no "query" of the value prior to the update.
>> [snip]