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

"Ged Byrne" <ged.byrne_at_gmail.com> wrote in message news:1102802872.069063.273450_at_z14g2000cwz.googlegroups.com...
> 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.

Yes, and that is fine -- I'm looking for big bang for the buck and if data can more easily be described by the user (that being a s/w developer, for example) as a graph, then why describe them as relations instead?

> The problem is not that these implementations are graph-based, but
> rather that they use pointers to describe and navigate the graphs.

I've asked about this before, but I must not understand "pointers" the way you are using the term because a) I think of pointers as an implementation issue having to do with storing locations and b) if you are using the term "pointer" as something logical, then how does it differ from a stored query (view) where there is join information? It is mathematically different, but what issues arise with it that do not arise when joining tables? In other words, just what is this "pointer problem" that supposedly contributed to the death of the (still lucrative for IBM, I suspect) IMS DBMS, for example?

> As
> the second great blunder states, this is what is wrong with them.

The only aruguments against pointers that I can find are not at the logical level of expressing a data model. The argument otherwise seems to be this "pointers are bad, we know they are bad because we said so way back when, and that is what killed the Network and Hierarchical databases, so we cannot have any new structures that have anything that we would term a pointer". Where can I find a better argument than that?

> 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);
> }
> }
>
> resuling in :
> AB
> AB
> true
>
> In this result foo is not equal to bar.
>
> public class Suprise {
>
> public static void main(String[] args) {
> String foo = "AB";
> String bar = "A";
> bar += "B";
> 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.

But if you use the equality operator, then you get the expected result. So, yup, if you use the wrong operator, you will get the wrong conclusion.

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

The .equals comparison is not based on that. The fact that there is another operator == is simply more flexibility, even if one first needs to learn the difference between the .equals and == operators.

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

And the reason that behind the scenes there can be no duplication would be?

Thanks. --dawn Received on Sun Dec 12 2004 - 02:25:22 CET