Hi Jakob,
I think you're on the right track. As you say,
> the tree structure of the acedb model and that of a document type definition
> (dtd) used to define these documents seem rather related.
and
> doing this with a traditional relational dbms seems to become
> overly complicated.
Right. The part I see as crucial is the implementation of 1-to-Many
relationships. xml incorporates this in a natural way. We need it, no
question. So xml includes it as an easy just-do-it. Doesn't try to
implement, it's only a flat file.
When the data gets bigger than manageable for flat files, how to implement?
rdbms: Every 1-to-Many is a "join". Even if the Many end turns out to be
null, you still took the performance hit to find that out. My Oracle bible
says five joins is pushing the edge on performance. The core problem,
integral to the rdbms paradigm and irremediable within it, is that
1-to-Many is actually implemented as Many-to-1, searching all the external
tables for which of their records link to the current item.
acedb: 1-to-Many links are direct, O(1). Instantaneous regardless of the
size of the data. As many as you want. For example my GrainGenes
schema for the Probe entity has 61 one-to-Many links currently. More
whenever I want. No cost.
As for Many-to-Many links, in rdbms these are a separate operation,
creating a relation table. I'm not sure how these affect performance from
the user side. Maybe no worse than any other join. In acedb they're
transparent. Some or all of my 61 may actually be Many-to-Many, I don't
even have to think about it, they're still O(1) for the user and no
complication for me.
- Dave
> From: "Jakob Fix" <jakob at free.fr>
> Subject: different use of acedb
> Date: Sat, 18 Mar 2000 22:56:54 GMT
>> hi,
>> i stumbled over acedb by reading a perl journal. i was wondering if anybody
> had any experience, or has any ideas regarding the use of acedb as an xml
> repository.
>> i am working on a project where there are rather complex, but well
> structured xml documents that need to be entered in some searchable database
> system. doing this with a traditional relational dbms seems to become
> overly complicated.
>> the tree structure of the acedb model and that of a document type definition
> (dtd) used to define these documents seem rather related.
>> any hints or ideas are very much appreciated. thanks in advance,
> Jakob.
>jakob at free.fr---
