Re: Date's First Great Blunder

From: Alfredo Novoa <>
Date: Fri, 16 Apr 2004 11:34:01 GMT
Message-ID: <>

On Thu, 15 Apr 2004 12:18:17 -0500, "Dawn M. Wolthuis" <> wrote:

>> >Not to me, it isn't. Mathematical models are simply models/metaphores.
>> They are formal representations.
>Yes, formal representations of a metaphore for whatever in the "real world"
>they are applied to

Mathematical models are not limited to the real world.

>> It should not have relationship with beliefs. It is proven that it is
>> simpler than the known alternatives.
>Simpler to human beings? Simpler to computers?

Simpler to humans of course.

> Simpler to work with
>mathematically? This is a RELIGIOUS BELIEF that if you take the simplest
>mathematical model (aka metaphor) for something, then that is the best.

Simplest leads to cheapest and money has nothing to do with religion (although the contrary is false :).

>> Most if not all of the advocates of the network and hierarchical
>> approaches never tried The Relational Model, thus their experience has
>> little value. It is hard to practice with something never implemented.
>The terms "Network" and "Hierarchical" were coined by relational theorists
>to disparage other approaches -- in other words, they are marketing terms.
>There are many people who persist data in trees (see your average file
>system, LDAP, DNS and many other repositories) or di-graphs (see the www).

If you don't like the terms I could say that it was proven that the logic based approach is superior to the graph based approaches.

>I am an example of someone who has used Oracle, SQL Server, My SQL, and
>PostgreSQL and much prefer the data model of the U2 databases (UniVerse and
>UniData). Why? Because I care about the cost of ownership for the overall
>software solutions over time. I am not alone in knowing and using
>relational databases and prefering not to.

None of the above is a RDBMS and My SQL is not a DBMS at all.

To use Oracle does not mean that you know how to take andvantage on The Relational Model.

I used navigational procedural approaches and the relational approach, and the differences in code size are in orders of magnitude. The differences in productivity between assembler and Java is very little compared to this.

>> I agree, although they are independent. Relational theory is for data
>> management and OO is for coding.
>Yes, but both are for developing software applications that meet the needs
>of people and organizations.

You can use The Relational Model to manage data and to use OO when you code the applications.

>> But there is one best approach for data management.
>Ah, there is that religion again

No, it is well stablished science teached at any university.

> -- I suppose the one best approach is to
>use the relational model? Yes that is king of the hill still in 2004, but
>it might be wise to keep your eye on the rear view mirror (to mix

I would be delighted to find something even better, but there is not any sign in the horizon.

>The objects that can be instantiated by a class are NOT "in" the class,

If class is definition this is evident.

If class is type then it is evident that objects (values) of a class are part of the class.

>while they are in the domain specified by the class. But again, this is a
>definition of terms. I someone wants to define class=type then I can play
>that game but I'd rather say that a class is a type definition or

That's the magic of OO. Everything might be anything.

The best definition of object is: an object is something.

Everything is something, thus everything is an object.

>> > I prefer to think of a class
>> >as a specification for (that is, metadata regarding) a domain/type.
>> It does not change the things a lot. The equation: type specification
>> = relvar is as blunderous as type = relvar.
>Is there such a thing as a relation as a type of attribute (as in
>"relational-valued attribute")? If so, then why couldn't a class be a type
>of relation?

Relations have type, you could call class to the type of a relation, but OO languages (still) don't support anything similar. OO types are scalar and relation types are not.

BTW you can not declare relation types in Tutorial D or table types in SQL. Regards
  Alfredo Received on Fri Apr 16 2004 - 13:34:01 CEST

Original text of this message