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

From: Dawn M. Wolthuis <dwolt_at_tincat-group.comREMOVE>
Date: Mon, 13 Dec 2004 08:16:47 -0600
Message-ID: <cpk88k$le8$1_at_news.netins.net>


"Alfredo Novoa" <alfredo_at_ncs.es> wrote in message news:41bd8eba.9956390_at_news.wanadoo.es...
> On Thu, 9 Dec 2004 20:42:18 -0600, "Dawn M. Wolthuis"
> <dwolt_at_tincat-group.comREMOVE> wrote:
>
>>I can use an OO language to define a
>>
>>public class Relation
>>
>>just as easily as any other type, right?
>
> Of course, but it does not mean that your class has anything to do
> with a relation.

Of course not! I was surely not implying that by naming a class "Relation" that it therefore is one -- I was saying that you can define one, however. What feature(s) of a relation make it impossible to define as an OO type? I can't think of any. If we look at our glossary for the def of "relation", can you pinpoint what aspect of that definition is unable to be encoded in Java, for example?

>>> It is not possible to use a class to define a relation type, but the
>>> 1GB has nothing to do with defining a class such as "Person".
>>
>>So, you can use a class to define a relation, but not to define the type
>>Relation, if I understand correctly.
>
> You can have a class named Relation but you can not define a relation
> type with an OO language.

Again, why not?

>>That is what I thought, which is why I used the example of Person (which
>>implements the interface "Relation" and could have a method of showAsTable
>>in it). Where is the problem?
>
> It has nothing to do with a relation type. The name does not make the
> thing. If not we could become very rich creating a class named
> OneBillionDolar :)

You cannot really think that my argument here was that because OO languages permit me to name a type "Relation" that ... anyway, this is a silly line of argument, so I'll stop contesting it.

>>Hmmm. So, the 1GB is only relevant when using OODBMS's
>
> The 1GB consists into think that relvars and scalar types are the
> same, but the example of TTM is about OODBMSs and OR mappers.
>
>>I'm probaby not using such a product, but I do have an imagination and
>>cannot yet imagine what the blunder is. Even if this is only relevant to
>>"persisting objects" in an OODBMS.
>
> You can read the pseudocode I posted.

I've had trouble with my news reader and am getting caught up, so I'll take a look.

>>> Of course there is, but only if you use an OODBMS or an OR Mapper.
>>
>>OK, so not just OODBMS's are the issue-- it is also an issue if you use an
>>OO language and an RDBMS too, right? I just not seeing a problem, either
>>in
>>theory or in practice. cheers! --dawn
>
> It is an issue if you are making a practical blunder because you think
> that relvars and types are the same thing, but in many cases it is
> hard to know what is the conceptual mistake that causes the practical
> blunder.

I'll read your psuedocode, but is there any product you can identify that has practical problems because of making this great blunder?

> In the case described by D&D the confusion between types and relvars
> is evident, but in many OO apps I have seen the mistake seems to be
> that the programmers think that the SQL DBMS is only a weird
> transactional file manager and the information must be managed by the
> application using network (graph if you prefer :) structures, like in
> the old days.

You mean the old days when it took a week to write and deploy a new accounts payable system? Silly programmers, they should know that projects take at least 6 months now. Yes, I know -- there are problems with those systems that we were addressing with DBMS's, but I fear we threw the baby out with the bath water (an overly disturbing metaphor, sorry).
>
> Regards

--dawn Received on Mon Dec 13 2004 - 15:16:47 CET

Original text of this message