Re: Logical equivalence of simple and complex types under the relational model?

"Costin Cozianu" <c_cozianu_at_hotmail.com> wrote in message news:314pe5F371n2cU1_at_individual.net...

> If you have to unravel the 7 components into individual variables, then
> you're right: non economy is done. But some computations can pass the
> entire complex value to let's say another function. And you wouldn't
> want that function to have 7 parameters instaed of one, would you ?

No, under model 1 I would pass address_id and under model 2 I would pass address

If I was not interested in the components.

Hopefully to put it more succintly:

What is the difference between a simple type with a unique identiifier and properties,
and a complex type with identity and components. Apart from the fact that properties begings with p and components with c.

Or put it another way. If there was no function "is-simple-value", how would you be able to see the difference between a complex and a simple type.

You might claim that property (relation) access looks different than component access, but this
is a merely syntatic difference in some specific languages.
>
>
> > Similarly you are assuming
> >
> > Update users set address= :new_address where user_id= :v_user_id under
> > model2
> > is different to
> > Update users set address= :new_address_id where user_id= :v_user_id
under
> > model1.
> >
>
> Yes, it is different.

And how?

> That would be the case with a client library. The notaion :param is
> customary for bound parameters to "prepared" statements from client
> libraries.

When one is using a non RM external programming language. A case that I have already said that I am not considering.

Rene. Received on Wed Dec 01 2004 - 11:53:32 CET