Re: Relation Schemata vs. Relation Variables

"David Cressey" <dcressey_at_verizon.net> wrote in message news:q3oIg.651$wI5.637_at_trndny04...
>
> "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.
>

What I'm trying to do is point out that relational assignment is not sufficient to provide support for transition constraints, that INSERT, UPDATE, and DELETE are not just shorthands for relational assignment, that there is a fundamental difference between them, that the root problem lies in defining a database as a container for relation variables where modifications are defined in terms of relational assignment, and that there is a more fundamental mechanism for modifying a database from which INSERT, UPDATE, DELETE, relational assignment and multiple assignment can all be derived. Furthermore, this more fundamental mechanism provides a means to define enforcible transition constraints declaratively, spanning multiple relation schemata, using standard relational operators from the algebra or the calculus, in the presence of volatile keys, without using surrogates.

>
>>
>>
>> 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.
>
>
>
Received on Mon Aug 28 2006 - 01:57:27 CEST