Re: A real world example

Brian Selzer wrote:
> "JOG" <jog_at_cs.nott.ac.uk> wrote in message
> news:1156039383.926159.159950_at_m73g2000cwd.googlegroups.com...
> > Brian Selzer wrote:
> >> It's possible for something to have its appearance altered without
> >> altering its
> >> essence
> >
> > 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.

With a surrogate you are representing that attribute anyhow. You're just completely wrong to hide it from the thing that needs to use it as identification. (all your examples rely on an entity having some sort of memory of what previous state it was in, which is an incredible assumption)

>
> >>
> >> >>> >> > 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]
Received on Sun Aug 20 2006 - 06:23:43 CEST