[
Lists Home |
Date Index |
Thread Index
]
There's no doubt that, for XML in, XML out applications, "native XML databases" can be a real boon. But that may not be enough.
At least with the implementations I am familiar with, natvie XML dbs do their own version of shredding. Randomly accessing XML document contents efficiently requires this. Now, their implementations are optimized for XML, an important difference from relational approaches, but their storage image is far from document form. So the term "native XML" is a bit misleading. It ain't native when it is stored. It just looks native when it is accessed. Relational DBs can do that, too, but not without a lot of configuration and some inherent inefficiencies.
Can an underlying relational mechanism also efficiently perform this storage image transformation in a highly automated way (without requiring extensive table definitions), and in a schema-independent way? Oracle is presumably trying with their update to 10g. Haven't looked at it- not even sure it is out yet- so I don't know whether they have succeeded or not. But relational models have shown themselves to be really flexible as compared to their hierarchical counterparts in the past.
And, of course, they don't have to be as good at it as a native XML DB. They just have to be good enough. The same "impedence mismatch" cry that the XML dbs are issuing now reminds the entire community an awful lot of the object-oriented dbs of the early 90s. Objects are pervasive in the computing environment, as XML is in the data exchange environment.OODBs still have their place- in fact, I'd love to use one in my current project, which is much more object-intensive than XML-intensive- but they have become niche players.
For the case with XML DBs to be different, I suspect XML has to pervade not only the messaging space, but also the execution space. Documents per se and DOMs kind of don't cut it. Perhpas there is an XML representation out there that does?
Linda
-----Original Message-----
From: Owen Walcher <xpriori@owenwalcher.com>
Sent: Aug 24, 2004 9:09 PM
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] are native XML databases needed?
From: "Chiusano Joseph"
> > > etc. (Possibly at this point you add in database constraints that
didn't
> > > previously exist, turn certain fields non-null, etc.)
> >
> > Sounds like you are using a relational database to store your XML. Talk
> > about an impedance mismatch. Why even bother with XML in the first
place if
> > you are shredding it or clobbing it?
>
> Perhaps because you have a system based on a relational database that
> has been in use for quite some time, and are using XML to exchange
> information with some or all of your trading partners - and you may not
> be able to justify ripping and replacing your relational system simply
> because an XML database is "better data management technology".
>
I hear what you are saying, Joe. In fact, I hear it a lot, but consider it
the normal rhetoric.
If that was a real reason, we wouldn't have relational databases today as in
the 80's we could have just continued to use our network and hierarchical
databases (just trying to follow your logic), upon which all our systems
were already built and running just fine (except they were hard to expand,
similar to the problems with relational databases and mature applications -
I am seeing a theme here). There are still MANY applications written on top
of IMS, or Dec RDBMS, or even VSAM. Does that mean we write new stuff on top
of that old technology?
So in the 80's, those with foresight said, yeah, I can do this the old way,
or I can do it the new way, and those that jumped on the bandwagon early had
a competitive advantage. In the 90's I converted my share of hierarchical
database applications to relational technology, because the time to
unload/change the schema/reload took more time than phone company billing
systems could be down (we are talking days here). Now everybody uses
relational databases, and those with foresight say "there is a better,
faster, easier way to do this". But most people are sheep, and do what they
know.
Fortunately, many of the regular contributors to this group know XML
technologies quite well (and I am thankful for the though provoking
discussion), but they still sprinkle their comments with "I know I should
do it different, but that is how I think, or that is what I know". With
XML, I don't try to convert applications, but wrap them into services, and
develop new stuff in the new paradigm, using ALL the new tools.
The original discussion was centered on all the layers of XML technology
(and options) used to do syntactic and semantic validations, and I believe
what everyone is missing from their XML stack is a native persistence
mechanism that does not require tons of glue code and O-R mappings just to
store the stuff. How many classes do you have to get data in/out of a
relational database, and convert it to XML or to your business objects? If
you could remove those from your code base, would it not improve quality,
shorten time to market, and dump the code everyone hates to write anyway?
Plus all the DDL your DBA writes, and normalization, and indexing, and
tuning SQL queries . . .
I will forgo the dis-assembling you car every night analogy that some folks
make, but the fact is: if you have to round-trip your XML to a client in
order to query, validate and or execute from it, then you will never be able
to scale (why do you think stored procedures were invented?)
So you have existing legacy systems built on relational DB's, and you have
already paid the tens of thousands of dollars per CPU for your Oracle or DB2
licenses. Let them run on into the future. The cost of the infrastructure
is miniscule to the overall lifecycle costs of an application. So quit
looking in the rear view mirror and start driving toward a complete
application solutions stack that is based on XML end-to-end, with little or
no impedance mis-matches along the way.
A very opinionated:
Owen
http://www.xpriori.com/developers/html/downloads.html
full disclosure: I am an independent consultant who provides services to
Xpriori as well as a number of other companies.
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
initiative of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>
|
