[
Lists Home |
Date Index |
Thread Index
]
OW>
Nagging:
Who's to say what XML was "designed for"? I thought it was designed
as a flexible meta-language that would grow and extend into things the
original creators never thought of (similar to HTTP, which I am sure TBL
never thought about web service and SOAP - but it STILL works :).
MK> The XML spec gives some quite good clues as to what it was designed for.
"Its goal is to enable generic SGML to be served, received, and processed on
the Web in the way that is now possible with HTML." The design of XML gives
further clues: if they had wanted to design something that could be easily
updated in-situ, they wouldn't have used a grammar that can only be parsed
by starting from the beginning. The terminology also gives clues: a unit of
XML information is called a "document", not a "database".
OW>
I have seen router XML files in the gigabytes (guess they should be
smart about partitioning into smaller documents?) I have seen text
documents in the hundreds of megabytes (I suppose they should use SGML). . .
and this is a problem people WILL have to address.
MK> I'm not talking about size, I'm talking about usage profile.
I don't think that using an XML document as a replacement for a
database is a particularly good idea
OW>
Are you strictly referring to relational databases, with their rigid
structures, files systems (which are themselves a data base), maybe a b-tree
or hierarchical or network set of structures? Maybe you have never worked
on a project that just wasn't suited for a "structured database", since the
data was often one of a kind (heterogeneity), often changing
(extensibility), and the data frequently needed to be repurposed for other
users downstream (adapatbility).
MK> If I had meant relational databases, I would have said relational
databases. I have worked on many projects over the last 15 years that needed
much richer structures than relational databases offer.
OW>
Like the Sedna XML database, NeoCore XMS allows these types of
changes in-place, in the database, without the need to round trip the XML to
a client machine. It is as simple as the Sedna database as well,
INSERT('<name>Jane</name>','/ND/Entry/name[.="Jon"]') You can find this
database with free, unrestrictive download at http://www.xpriori.com/ And I
don't think they tell you how to use it, you can use it for whatever you
want, including managing large heterogenous XML documents.
MK> I have no problem with the concept of XML databases, merely with the
concept of trying to use a single 50Mb document as if it were a database.
This particular document apparently contains elements called <Entry>, and my
first instinct (of course we haven't exactly seen the full project
requirements) would be to map each Entry to a persistent XML document.
(What I would really like to see is an XML database that gets rid of the
concept of "document" entirely. But we're a long way from that at the
moment. In all the systems I've seen, the choice of "what is a document" has
a profound effect on both the physical and logical design, and as a general
rule of thumb, many small documents works better than a few large ones.)
Michael Kay
|
