Re: RM and abstract syntax trees

On Nov 12, 7:35 am, "David Cressey" <cresse..._at_verizon.net> wrote:
> "David BL" <davi..._at_iinet.net.au> wrote in message

[snip]

> > Despite such an important and useful
> > distinction, it is only relevant to the underlying physical
> > implementation of the Persistent Object Store (POS). It has no impact
> > whatsoever on the fact that clients of a POS like to think of OIDs as
> > persistent pointers between objects.
>
> I tend to use the acronym "POS" with a different expansion, but we'll let
> that pass for now.

I prefer POS to the more conventional term OODBMS because it seems an oxymoron, and could help naive developers think that a DBMS doesn't need the RM.

> It may or may not have any impact on what the clients like to think. It
> does however have a great impact on the delay time needed to access the
> thing referenced by the pointer.

Perhaps in the opposite direction to what you think. A POS using logical OIDs can outperform one with physical OIDs. The former allows for objects to easily be reclustered on disk, and localised graphs of interconnected objects can use localised OID values (simply by being careful with the OID allocation strategy) so that with some reasonable caching of the indexing structures, there are minimal amortized harddisk  seeks required to traverse the indexing structures.

> It also has a great impact on the
> consequences of shuffling data within the address space. (What you are
> calling "swizzling" might be the same as what I'm calling "shuffling".

Pointer swizzling refers to the mapping from OIDs to virtual memory addresses as objects are faulted into memory.

> If there are physical pointers beyond the control of the DBMS, then
> shuffling data can result in the invalidation of such pointers with no
> possibility of raising an exception at the appropriate point in time.
>
> So we can at least table the discussion on terminology by agreeing that
> "pointer", in strict usage, should ONLY refer to physical OIDs.

I don't find that restriction on "pointer" reasonable.

> Logical
> OIDs could be compared to "surrogate keys", but a discussion might ensue
> about whether dependence on them adds to complexity with adding to
> expressive power or flexibility.

> That's the issue I'd really like to grapple with. It seems to me that the
> people who model the connection between items of data based on logical OIDs
> create a monster that has all the defects of graph based databases, coupled
> with the access overhead associated with content based addressing. In other
> words, the worst of both worlds. If that's true, that would be a fairly
> convincing argument for finding a different way of modeling data and
> designing databases.

Don't dismiss the utility of logical OIDs in the implementation of a POS. [snip] Received on Mon Nov 12 2007 - 02:21:47 CET