Re: 1GB Tables as Classes, or Tables as Types, and all that refuted

From: Alfredo Novoa <anovoa_at_ncs.es>
Date: Wed, 24 Nov 2004 02:17:34 +0100
Message-ID: <h2o7q01bbgv1kvsato31bhsnol5bku6q7s_at_4ax.com>


On Tue, 23 Nov 2004 10:40:02 -0800, Costin Cozianu <c_cozianu_at_hotmail.com> wrote:

>So don't ask him to provide a summary definition for a variable, because
>he has none.

Of course I have a definition for a variable. I posted it many times:

Variable: a holder or a container for a value. The value placed in variable may change over the time. To say a variable holds a value means that an encoded representation of a value is contained in the variable.

> Such a definition would require formal (mathematical)
>semantics for the model he is defending. And there is none yet.

You always use the same trick to dismiss anything you want, but you never offer any argument nor any alternative definition.

I checked the books you recomended and I have not found any decent definition of type, variable, value or operator.

BTW I am not defending any model here. I am only saying that types and variables are fundamentally different. This should be out of question.

>But to answer your question: in Date's sketch of a model called the
>third manifesto, a type is a name that denotes a "set of values".

Wrong, according to Date a type is a NAMED set of values with their associate operators.

BTW I disagree with Date about that a type always have a name.

> The
>difference between the type's denoted set of values and the set of
>values denoted by a "relvar" (aka table in common speak) is that the
>later is time varying while the former is fixed in the abstract.

A relvar holds a single relation value, and the type's denoted set of values might be any set of values: scalars, matrices, vectors, etc, or even any combination of scalar and non scalar values.

> The
>next step is to consider the mapping between the name of the type

But you said that a type is a name. Another inconsistency.

> and
>the set of all values of that type ( therefore the subset of the fixed
>immutable set)

The relation value holded in the relvar is a subset of the set of all relation values. Let's see where you want to go with this chain of incoherences.

> that are instantiated within the database (i.e. stored in
>a column, in a row, or in a whole table somewhere in the database.

Now you are completely lost. This is surrealist, you are interchanging the relational type of a relvar and the types of the attributes.

> And
>the later is a time varying set that can just be as easily thought as a
>relvar, because maps a name (the name of the type) to a time varying set.

In a short: What you are trying to say is that we can hold all the values of a type in a relvar.

Of course!

For instance if we define a type constituted by the natural numbers which are less than 10 and the appliable operators, we can create a table of integers and to store those numbers on it.

So what?

What a waste of time!

This is of course very different to: types and variables don't have any fundamental difference, which is the essence of 1GB.

>Depending on the circumstances of the design needs, the schema can make
>this mapping explicit, like in the example I presented from User type to
>the Users table

It that example you were mapping a collection of User typed objects to an Users table.

>, and there's *absolutely nothing wrong with that*. As

 I prefer to map a variable of class RelVar to the Users table.

Regards Received on Wed Nov 24 2004 - 02:17:34 CET

Original text of this message