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

From: Costin Cozianu <c_cozianu_at_hotmail.com>
Date: Wed, 01 Dec 2004 07:47:03 -0800
Message-ID: <3167cfF379ukqU1_at_individual.net>


Rene de Visser wrote:
> "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
>

But under model 1 address_id is superfluous. It is an entity that is entirely unnecessary !!! Plus you'll pass an address_id to the function and that function has to look in some global_addresses table. You increased the coupling and put entirely gratuituous constraints on the design.

Maybe I don't want to have a global_addresses table with some ridiculous address_id to take care of.

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

There's no need to have "identity" for values. Values are self-identifying. If you have the number 3 you don't need an 3_ID for it to identify. So if you have the address ((zip 1234) (street "X no 4") (country "USA")) that's your value right there, just like the value 3.

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

The difference is by construction. Types are constructed according to an algebra of types (type system) starting from primitive values (bool, int, char, string, etc).

Types that are derived from other types using composition operators (ARRAY, RECORD, UNION, "->", etc) are composite types.

> You might claim that property (relation) access looks different than
> component access, but this
> is a merely syntatic difference in some specific languages.
>

No I don't want to claim anything more, other than you need to read a good introduction on type theory :)

Cheers,
Costin Received on Wed Dec 01 2004 - 16:47:03 CET

Original text of this message