Re: Relation Schemata vs. Relation Variables

"Bob Badour" <bbadour_at_pei.sympatico.ca> wrote in message news: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.
>

No, it's not what I'm saying at all. I used the example of a triggered procedure as an illustration of the problem, since the underlying theoretical problem mirrors it. What I'm saying is that transition constraints can be defined declaratively, without using triggered procedures at all, but not only by comparing the current set of tuples with the proposed set of tuples.

> If the dbms tells the triggered procedure that a set of replacements
> happened, it hands the correlations over on a silver platter...

It hands over the correlations one at a time, and if there are intrarelational dependencies, you're screwed. Furthermore, a dbms that hands over correlations has provided an implementation-specific extension to the model as it is currently defined by D&D. That's why many applications that were written for DB2 don't run on Sql Server, and why many applications that run on Sql Server don't run on Oracle. So, depending on an implementation-specific extension is contrary to the concept of data independence. Received on Mon Aug 28 2006 - 00:55:09 CEST