Re: Relation Schemata vs. Relation Variables

From: Bob Badour <bbadour_at_pei.sympatico.ca>
Date: Sun, 27 Aug 2006 21:41:20 GMT
Message-ID: <4koIg.2409$9u.42767@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 - 16:41:20 CDT