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

Dawn,

The problem is that if you allow these models to take the descriptions 'Graphs' and 'Trees' you are covering the fact that these mathematical constructs are also describable using Relations.

The problem is not that these implementations are graph-based, but rather that they use pointers to describe and navigate the graphs. As the second great blunder states, this is what is wrong with them.

I haven't any experience with network databases, but I am well aware of the problems that it causes in programming.

In the following java, foo is equal to bar:

public class Suprise {

public static void main(String[] args) { String foo = "AB";
String bar = "AB";

System.out.println(foo);
System.out.println(bar);
System.out.println(foo == bar);

System.out.println(foo);
System.out.println(bar);
System.out.println(foo == bar);

result:
AB
AB
false

Why? Because the identity of foo and bar are not defined by their content, but instead by the address in memory that is allocated to store the strings.

What this problem really boils down to is that the graph contains duplication. The single string, 'AB', has been duplicated within the graph. Two different nodes in the graph defined for the implementation correspond to a single item in the conceptual model. Since the equals comparison is based upon the nodes in the implentation graph, they return a conceptually incorrect result.

What the relational model does is to provide a means in which to create an implementation model that does not contain any duplication. If a model is correctly normalised, then it is guaranteed that it contains no duplication.

As far as I am aware there is no process that can provide similar proof that a graph described using a network of pointers contains no duplication. Received on Sat Dec 11 2004 - 23:07:52 CET