Re: Relation Schemata vs. Relation Variables
Date: Sun, 27 Aug 2006 21:41:20 GMT
Message-ID: <4koIg.2409$9u.42767_at_ursa-nb00s0.nbnet.nb.ca>
David Cressey wrote:
> "Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message
> news:hIhIg.2199$9u.39081_at_ursa-nb00s0.nbnet.nb.ca...
>
>>David Cressey wrote:
>>
>>
>>>"Brian Selzer" <brian_at_selzer-software.com> wrote in message
>>>
>>>>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.
>
> I was trying to stay away from dbms internals, as much as I could, because
> Brian keeps saying that his idea is not at that level.
>
> As I've said fairly often, DEC Rdb/VMS is the only implementation I'm
> familiar with at the internals level.
> Rdb stores table rows in a data structure that, internally, is called a
> "record". (I can hear Joe Celko warming up his blowtorch now.) Updating a
> table row would involve locating a record that contains the "old tuple",
> and replacing the record contents with the "new tuple". Aside from a little
> space management, index updating, and before-image maintenance (for the
> sake of snapshot transactions), it's no big deal.
>
> I believe what I've just written is nothing more than a specific
> implementation of what you have described above.
>
> The thing is that this is all done out of sight of the database-client, and
> whether this is an update of type 1 through 5 (using Brian's prior example)
> is of no consequence to this layer of the Rdb software. Hell, it could even
> be an error correction or a roll-forward after a database restore.
>
> I get the impression that Brian is trying to construct a new flavor of
> client-server interface, one that would permit his definition of transition
> constraints to be easily implemented. That's the part I'm not following.
No, he's a self-aggrandizing ignorant constructing a straw man to make himself look far more important than he really is.
>> 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? >> >>If you are going to pretend to engage the self-aggrandizing ignorants, >>please do a better job of calling them on their bullshit. What is the >>point of asking him about the details of a straw man? It's a straw man. >>'Nuff said.
>
> I'm still not convinced that it is a straw man. I'm by no means convinced
> that it isn't a straw man, either. That's why I'm probing.
It's a straw man. He's saying: "If the dbms tells a triggered procedure that some set of tuples was replaced with some other set of tuples, I cannot tell if there is a correlation between them." But there is no reason why the dbms would necessarily do that. It could just as easily tell the triggered procedure that a set of replacements happened.
If the dbms tells the triggered procedure that a set of replacements happened, it hands the correlations over on a silver platter... Received on Sun Aug 27 2006 - 23:41:20 CEST