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

Dawn,

You are exactly right.

1. Data should be easy to describe. This is something that OO gets right and SQL gets wrong. The goal of the TTM is to make working with views the same as working on base relations. This will allow the user to work with the view that is most expressive and convenient.
2. Pointers are purely an implementation matter. 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. One-to-many or many-to-many relationships are mapped by means of collection classes that get populated at run time.

This is all rather vague. I'm writing up a much more detailed blog on all of this which I hope to publish over the holidays. I'll post to the group about it when it's ready.

3) In Java you do have to separate equality operators, the == operator that tests for referential equality and the .equals() method. Implementing the .equals() method is the developers responsibility, and is usually based on three separate notions of identity within the object model. Most implementations of equals compare first the reference, then the hashcode and finally the individual member variables.

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

4) There is nothing wrong with duplications behind the scenes. However, at the moment the duplication is right up front, and this is a fault of both OO and SQL.

For example, in SQL databases tables have to be denormalised, reintroducing duplication, for the sake of performance.

If views were properly impelemented this would not be a problem. Just as the user can work with a view, the model can be implemented on disk as a denormalised view. This would have no effect on the conceptual model. Received on Mon Dec 13 2004 - 05:15:46 CST