[
Lists Home |
Date Index |
Thread Index
]
Didier PH Martin <martind@netfolder.com> writes:
>
> Hi Ken,
>
> Thanks for the links, this is very useful information.
>
> I followed this thread with a lot of interest. Recently I had
> to work on new data structures to store objects. After a lot
> of discussion with different groups it appeared that what
> developers like about the relational model is the capacity to
> merge or "blend" data from different sources (i.e. tables,
> fields). What is appealing in object database is the capacity
> to link objects or create associations between objects. The
> problem is that today you only get one or the other.
I believe you can do it all: you can model tree structures and
generalized graphs in a relational database. The resulting schema may
not look like anything normal relational modelers would endorse, but
with a lot of work can even be made to have good performance.
> It seems that the ideal storage would be one that allows
> creating new objects by "blending" other objects and still
> allowing links or association to other objects. Some people
> proposed using a subject based approach but very few concrete
> proposals are on the table form the academic community.
I've come to the conclusion that if you want a relational model you've
got to start from a relational database (the OO DB vendors of course may
disagree). The biggest issue is how to manage the metadata: at what
point are you reinventing a DB on top of a DB? Having taken the plunge I
can say two things: we still go back and forth on how much metadata to
manage ourselves (vs. letting the DB do it), and one persons metadata is
another persons data: having a DB that does not allow you to treat
metadata as data will stop you dead in your tracks on this quest.
I've got the start of a white paper describing the general approach on
how to do this. My timeline for completing the paper and doing a
prototype implementation is multiple years, too much legacy application
migration to do to get there in any shorter period, though there's a
tiny chance that could change if we ever get the resources to fork a
research project.
> In a nutshell the ideal storage system would be as versatile
> as relational databases to "blend" or merge data and create
> new ones. In fact, a table can be perceived as a frame (a
> method-less object). Hence, relational databases allow
> creating new frames from existing ones. It would also allow
> creating associations between objects and let us type the
> links, for instance to allow the creation of standard
> associations like composition, aggregation, inheritance and
> new non standard ones.
Yes! Our basic model is more or less: pick your favorite relational
approach for doing a hedge structure, add tables for doing self joins on
typed relationships, add tables for doing the node storage, normalize
everything out. Then you have to decide what approach you're going to
use to annotate the metadata that you need on top of the relationship
representations and things start getting interesting...
> I personally find XML a very good representation language but
> not very efficient as a permanent storage mechanism.
I agree, with the model I describe, generation of XML from the DB is
trivial (after you've spent a year or two simplifying the code down to
the basics). Insert and update costs also turn out to be low.
> Using
> XML I found XSLT or XQuery very useful to blend new
> representations for existing ones. Xlink has been quite good
> to provide an inheritance mechanism. The more I play with it,
> the more I find Xlink inheritance mechanism of great value.
> For example, I can write an Xlink processor able to process
> any king of documents having elements inheriting the xlink
> characteristics. It is easier to create a separation of
> concern when processing data representations. In fact, I was
> able to re-create the composite pattern using xlink
> inheritance (or architectural form for SGMLers). I used
> xlink:role to "type" the kind of link, for example, an
> aggregate reference would be an xlink:role="aggregator". It's
> unfortunate that the community wasn't able to recognize the
> full potential of xlink and in general the inheritance
> mechanism proposed by such tool.
Haven't explored Xlink: using Cocoon and aggregation (and some of the
newer Cocoon features for flow manipulation of multiple XML pipelines) I
suspect we've negated much of the need for it. Then again all our XML
manipulation is purely local, do you think we'd see more value in Xlink
if we where aggregating non-local XML?
|
