Re: Relation Schemata vs. Relation Variables
Date: Sun, 27 Aug 2006 14:09:17 GMT
Message-ID: <hIhIg.2199$9u.39081_at_ursa-nb00s0.nbnet.nb.ca>
David Cressey wrote:
> "Brian Selzer" <brian_at_selzer-software.com> wrote in message
> news:rn1Ig.12260$1f6.6985_at_newssvr27.news.prodigy.net...
>
>>"David Cressey" <dcressey_at_verizon.net> wrote in message >>news:c8YHg.45$8Q6.5_at_trndny01... >> >>>"Brian Selzer" <brian_at_selzer-software.com> wrote in message >>>news:vYJHg.17542$gY6.10049_at_newssvr11.news.prodigy.com... >>> >>>>>>>A small digression: all this reminds me of the (in)famous SQL >>>>> >>>>>construct: >>>>> >>>>>>>UPDATE .... WHERE CURRENT of <cursor> >>>>>> >>>>>>That's probably because it hasn't clicked yet that a transition is a >>>>>>*set* >>>>>>of triples, where each element represents only a distinct component
>
> of
>
>>>>>>the >>>>>>overall difference between the current database state and a
>
> /possible
>
>>>>>>state/. The above construct involves something that passes over a >>> >>>result >>> >>>>>>set in a particular sequence. That's a totally different thing >>>>> >>>>>altogether. >>>>> >>>>>I'm well aware that you are talking about a set of transitions. Your >>>>>professional history of dealing with bozos has conditioned you into a >>>>>habit >>>>>of condescension that is out of place in this newsgroup. >>>>> >>>> >>>>I ASS-U-MEd that you were confusing triples with transitions because of >>> >>>the >>> >>>>digression below. I was wrong, and I apologize. I did not intend to
>
> be
>
>>>>condescending. >>>> >>> >>>OK. No harm done. The subject of UPDATE ... WHERE CURRENT is worth a >>>side >>>discussion here, because >>>it blurs the distinction between content based addressing and location >>>based >>>addressing. The CURRENT row of a result table is like "the can of >>>Campbell's chicken noodle soup that I have in my left hand", although
>
> at
>
>>>a >>>different level of abstraction. >> >>I see your point. On the other hand, since the set of triples in a >>transition describes the entire difference between two successive database >>states, it is not exactly the same thing.
The set of triples does that in the hypothetical implementation of 'on update cascade' that Selzer made up.
> Does the set of triples describe the entire difference or does it prescribe
> the entire difference?
The question to ask oneself is: "What relevance do these implementation details have to any theory?"
>>The idea of location based >>addressing doesn't have any place in the conceptual or logical models.
>
> Agreed.
True, which is why another implementation might use physical location internally and represent it differently to the user. For example, consider an implementation that represents the update to the triggered procedure as a single relvar with two attributes 'new' and 'old' where each attribute is a relation valued attribute with a type that is a sub-type of R's constrained to at most one tuple. Such an implementation can associate individual tuples in the initial state with individual tuples in the final state using physical location but the user always interacts with relvars and relations.
>>What >>I'm trying to point out is that how tuples correlate during an update is >>something that either the database designer must specify, or that the user >>must specify, or both.
>
> Here's where you're losing me. What does this "correlation" signify?
He isn't losing me. He is just flat-out plain old wrong. The dbms can correlate tuples during an update by physical location. After all, the dbms has access to and manages the internal physical representation of the data.
Does
> it mean that the old tuple and the new tuple
> both refer to the same item in the universe of discourse (subject matter)?
> Does it mean that the old tuple and the new tuple are both stored in the
> same row of the same table (implementation)? Or does it means that the new
> one "replaces" the old one in the sense of overwriting the old one in some
> (part of) a variable? Or something else?
Who cares? He is a self-aggrandizing ignorant who demonstrably talks gibberish. Even if he accidently manages to reply with something that sounds cogent, how will you know whether he understands what he says the same way a normal educated person would understand it?
>>The database designer specifies it with a >>system-generated surrogate.
>
> would you explain this a little more clearly?
Why do you keep inviting him to waste more of everyone's time?
[yet another idiotic straw man snipped]
> In the five updates above, you are updating one or both of the candidate
> keys. Earlier, you said, IIRC, that keys should be immutable. Why isn't
> this a contradiction?