Lists Home |
Date Index |
I doubt you are in the minority. There have been multiple threads
here comparing implementation strategies for so-called "XML Databases".
Relational systems are mature with respect to optimization, indexing,
and have a large and skilled user community. They scale nicely for
very large systems for all the reasons we know about. XML databases
using non-relational implementations exist and are progressing
nicely but are not as mature nor as experienced.
XML is meaningless. XML-only is the same. Nice format for archival,
on the wire representation, and human comprehension. The infoset-level
data structures are ok for the jobs most put them to, in-memory work
for transformation, getting and setting limited size value sets, and
so forth. Useful when a large system or set of systems must cooperate
to perform tasks at the loose level of represenational state transfer.
Given that entities work, fragments work. The problems are indexing
and normalization just above the metal, but a whole host of social
issues after that which are the same for relational or any other
implementation framework. I'm always glad to see anyone take up
this topic. Fresh eyes and all that.
The markup community at large knows all of this, has known all of
this since before SGML, and continues to explore options. We do not
limit ourselves in any meaningful way except to insist on a
meaningless standard, and for integration of very large systems,
that has made all the difference. In other words, try it in
a relational system without markup and see the other side of the
difficulties. Because many of us have worked with or implemented
document management systems for three decades, we are well-aware.
What is a 'document file'?
From: Mitch Amiano [mailto:email@example.com]
Ok, I'll just come out and say "that's stupid".
"XML only" simply doesn't make sense. There is no such thing.
It seems contrary to the whole point.
But maybe I'm in a minority.
> Ummm, the situation presented is that an XML only solution set can
> provide the needed functionality, response time, and other capabilities.
> No worries here that I can do this using a relational DBMS, normal
> forms, etc. But doing it only using XML constructs, and tools specific
> to XML, does not seem doable, reasonable, appropriate or supportable
> over time.
> Someone told me, verbally, and emphatically, that it is doable in XML
> only constructs, to which I replied "Show me." and from whom no such
> demonstration has been forthcoming. I think they said that because the
> XML tech community, as a general rule, limits it discussions to
> generalizations specific to small data stores, which is fine in and of
> itself, but which leads to grave errors otherwise.
> Also, I have to smile when someone says something like "implement XML
> within a relational database".
> Thanks for your response, and in my opinion you are exactly and
> precisely correct. Delivering this functionality on this scale using the
> currently available computer hardware and connectivity almost without
> exception requires the use of normal forms, and normal forms are best
> implemented in a dbms, not a document file.