Re: Date's First Great Blunder

From: Dawn M. Wolthuis <dwolt_at_tincat-group.com>
Date: Fri, 16 Apr 2004 07:19:15 -0500
Message-ID: <c5oj0f$255$1_at_news.netins.net>


"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:407fb4d1.1060625_at_news.wanadoo.es...
> On Thu, 15 Apr 2004 12:18:17 -0500, "Dawn M. Wolthuis"
> <dwolt_at_tincat-group.com> 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 :).

Bingo! So, we ought to be able to get some emperical data. If such a study is done fairly, what will it show about the cost of ownership of an RDBMS compared to a PICK implementation?

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

Now we are getting somewhere -- I have heard relational theorists make this claim often -- is there emperical data to "prove" this claim or is this one of those "I made the rules of the game and then I won the game" statements? I have honestly searched for such proof and cannot find it.

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

So, we have a theory and no implementations so it is impossible for us to know whether the theory is useful or not? I won't hold my breath for an actual consumer product that is deemed good enough for us to test the theory. And, by the way, since Codd's first relational theory paper was published by ACM in 1970, what is keeping us from having an implementation these many years later? I'll admit there are no perfect PICK implementations by a long stretch, but the first implementation of it was, indeed, an implementation.

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

I will completely agree that I am no expert on the relational model, but I am here as a student.

> 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 care naught for code size. In the 80's when I had COBOL programmers working for me (and was one myself), the anecdotal evidence I saw that the really excellent programmers often produced many fewer lines of code than their average-programmer counterparts was overwhelming. Additionally, I find "lines of code per function point" comparisons of computer languages to tell us nothing about productivity in the language. It is good to see our profession attempt to get some solid metrics, but what a silly metric that one is!

> >> 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 I only work with applications whose purpose is to manage data ;-) [don't respond to that one IYKWGFY]

> >> 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 have yet to find proof that the relational model is better for a company to use than any other data model. My anecdotal evidence tells me otherwise. Where is the emperical data?

> > -- 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
> >metaphors).
>
> I would be delighted to find something even better, but there is not
> any sign in the horizon.

I suspect this has to do with what we are trying to do with the model. I'm after the best total cost of ownership for software applications.

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

Yup, agreeds.

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

In what way are they scalar? I suspect this is a def thing too. It seems to me that one could have an array as an object (loose terminology), right?

>
> BTW you can not declare relation types in Tutorial D or table types in
> SQL.
I know -- what a shame, eh? smiles. --dawn Received on Fri Apr 16 2004 - 14:19:15 CEST

Original text of this message