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

"Alfredo Novoa" <alfredo_novoa_at_hotmail.com> wrote in message news:41bdc816.24640109_at_news.wanadoo.es...
> On 13 Dec 2004 03:15:46 -0800, "Ged Byrne" <ged.byrne_at_gmail.com>
> wrote:
>
>>1) Data should be easy to describe. This is something that OO gets
>>right and SQL gets wrong.

Good write-up, Ged. I look forward to your blog write up.

> Data are facts and OO is not about describing facts.

Says who? That is at least a part of what it is about, right?

>>2) Pointers are purely an implementation matter.
>
> No, a pointer is anything that points to something. Pointers are a
> fundamental part of a graph based model.

Alfredo, since this is clearly fact plus definition-based information and we disagree on it, we ought be able to resolve this. How is a foreign key NOT a pointer while information that defines the path from one node to another IS a pointer in some way that is problematic for the latter and not the former? I honestly think you are wrong on this, but it is even more important to me that I understand this issue and understand why people think there is something pure about foreign keys in relational models, but not in graph models. Thanks for your patience in helping arrive at a statement about this with which we both agree and that addresses the issue of pointers and data models.

>> The problem is that
>>the way that objects are constructed in languages such as small talk
>>and java means that the logical model is incomplete without these
>>implementation details.

We can talk about the Java use of references without discussing it as a physical implementation detail, right?

> The logical models are incomplete without this logical concept. A
> network model without pointers is like a relational model without
> relations.

Again, I think that a graph model without edges is like a relational model without foreign keys, but if that is not what you mean and if you think that the definition of a logical edge is somehow inferior to the specification of a foreign key, then I just haven't found the logic to support that.

>>3) In Java you do have to separate equality operators, the == operator
>>that tests for referential equality
>
> In other words: it tests for pointer equality. Pointers and references
> are the same thing.

But the problems with pointers were related to maintenance of the database and not related to the logical modeling of data, right? I think you are mixing up an old version of pointers that were inefficient and hard to maintain with a logical notion.

> In the OO world, to think that two different things are the same thing
> is as common as to think that two synonyms represent different things.

In the OO world, there is acknowledgement that there are different meanings to equality. There is a difference between the value of two variables being the same object and two variables being different objects but having the same value. This rarely confuses me when I'm coding, although it did when I started working with OO. Where is the logical problem in this? If I had a great piece of chocolate cake and you had a great piece of chocolate cake, it makes sense for us to determine if we each had a piece of the very same cake (== operator) or if they were from two different cakes made from the same recipe (.equals() operator).

Similarly within a database, if I we have two propositions:

Jane Doe has a yellow 1967 Mustang fastback John Doe has a yellow 1967 Mustang fastback

and another proposition
Jan Doe is married to John Doe

Then it makes sense to ask if there are two such Mustangs in this family or one that both claim to own. There is no logical error in the OO approach to equality as best I can tell.

>>Obviously this works, Java works, nobody is disputing this. The
>>question is, does it really have to be this complicated?
>
> The answer is: no.

I agree with both of you on that. --dawn Received on Mon Dec 13 2004 - 22:19:17 CET