Re: Relation Schemata vs. Relation Variables

"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.

>
>
> 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 Sun Aug 27 2006 - 23:23:34 CEST