Re: Date's First Great Blunder

On Fri, 16 Apr 2004 07:19:15 -0500, "Dawn M. Wolthuis" <dwolt_at_tincat-group.com> wrote:

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

I am sure about it will show that an RDBMS is a lot cheaper.

The problem is that we don't have RDBMSs to do the study.

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

Anecdotal evidence is not necessary and it does not prove anything in maths.

>I have honestly searched for such proof and cannot find it.

See the Relational Database Writings series.

And also this for instance:  

http://www.intelligententerprise.com/db_area/archives/1999/991105/online2.jhtml

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

Even the bastardized implementations are very useful at practice and they replaced the alternatives in most scenaries.

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

IMO the major component is ignorance.

The model was never understood by the masses.

The first dirty, flawed and incomplete prototypes were so successful that a correct implementation was forgotten.

When the flaws and limitations arised they were attributed to the model instead of the flaws of the implementations and some people returned to the primitive approaches. Sad, but true.

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

I am talking about the same programmer and differences of more than a 90%

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

It is silly to apply it blindly but it might says many things.

I am sure about I prefer to mantain 2000 lines of high level code instead of 50000 lines of assembler code.

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

They have visible components.

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

Yes, an array type is a good example of non scalar type. IMO all OO languages should implement relational variables besides array variables. It would be the end of the called "impedance mismatch".

>> BTW you can not declare relation types in Tutorial D or table types in
>> SQL.
>
>I know -- what a shame, eh?

No, I don't think they are very useful and it would be very easy to implement that.

Regards
  Alfredo Received on Fri Apr 16 2004 - 16:36:18 CEST