From: Laconic2 <laconic2_at_comcast.net>
Date: Sat, 29 May 2004 08:42:21 -0400
Message-ID: <4ZydnbnwtcNGGSXdRVn_iw_at_comcast.com>

In the ongoing discussion here about alternatives to the RM, the subject of pointers keeps coming up.

AFAIK, one of the features of the RM is that the interconnectedness of data is established by common data values, instead of pointers.

In my view, pointers are "good things" not "bad things". But there are plenty of "good things" that will harm you if you don't use them right. One of the ways a network or graph data base achieves performance is by the efficient use of pointers, and the strategic preplacement of pointers where they will be needed for navigation.

In the RDBMS implementations that used tables and indexes to represent relations and navigational aids, there are plenty of pointers. Indexes are full of pointers. And there are various kinds of pointers, behind the scenes, that allow a table scan to be quicker that an entire database scan. (of course, no one would ever build a product that relied on a database scan for scanning a table, I hope).

But tables don't have pointers in their column contents. (Except where the RDBMS has a primitive datatype like DBKEY). And that allows certain predictions that the RM makes to be made with fair certainty. That's one of the "good things" about the RM.

On the subject of WHAT vs HOW, I don't even place pointers on that spectrum. Pointers are about WHERE, not about WHAT or HOW. Indexes juxtapose WHAT (the index key) with WHERE (the pointer to the row).

Or am I wrong in this? Received on Sat May 29 2004 - 14:42:21 CEST

Original text of this message