Re: [xml-dev] XML Database Decision Tree?

[Dan Weinreb <dlw@exceloncorp.com>]

   Date: Fri, 19 Oct 2001 23:49:00 -0700
   From: Ronald Bourret <rpbourret@rpbourret.com>

   But what I'm not convinced of is that, should native XML databases
   succeed, the bureaucracy controlling what goes into the database won't
   try to take them over. 

But what do you mean, in this context, by "succeed"?  If the native
XML DBMS's succeed in supplanting the relational DBMS's, and taking
over their role as the "database of record" for the classic kind of
key corporate data that has to be accessed by many different groups,
then yes, the DBA's would then become the lords of the native XML
DBMS.

However, I don't think that's the kind of "success" that native XML
DBMS's are currently looking for.  I think it would be very hard for
them to succeed at that.  Why should people currently using RDBMS's
for their classic key corporate data have any interest in converting
to XML as a data model?  After all, the relational model basically
serves their needs pretty well.  There is not currently an industry
crisis among RDBMS users caused by deficiencies in the relational
model.  Furthermore, changing the data model in such systems from
relational to anything else would entail a huge amount of work and
risk.  A vast superstructure has been built around these relational
databases: report generators, reports written for those report
generators, all kinds of tools and add-ons from the relational
database vendors, the fact that lots of people have been trained in
concepts of third normal form, the SQL language, and so on and so
forth.

The image of native XML DBMS's trying to supplant relational DBMS's,
trying to take them over and replace them, is a strawman, and we need
not waste our time thrashing it.

I think the problem arises from the use of the term "DBMS" (or
"database"), because it can be interpreted in a narrow sense or a
broad sense.

In the narrow sense, a DBMS is in charge of the "data of record"
holding classic key corporate data, being used by many groups for
widely different purposes and widely different computing environments,
supporting ad hoc queries, and on and on.

In the broad sense, a DBMS is software that manages data, doing some
useful things for you.  There is a long menu of data management
services that you might want or not want.  Any application needs a
certain subset of these services; any DBMS-in-the-broad-sense)
provides a certain subset of these services.

When we use the phrase "native XML DBMS", I think we are using DBMS in
the broad sense.  Of course the broad sense is a lot less specific,
since it doesn't say which of the services we're talking about.  So
it's hard to generalize about native XML DBMS's.  In order to get
specific and get down to the real facts, you have to talk about use
cases: what is the native XML DBMS for in this case, and what are its
responsibilities in this case, etc.

   I think this is a very good point. Native XML databases look like a good
   way to integrate data from a variety of backends, and I think the
   winning native XML databases of the future will do this transparently
   and bi-directionally. (Some are already doing it today.) Relational
   databases may have problems in this area, since the result of
   integrating data from a variety of sources is likely to be
   semi-structured data, not structured data.

   -- Ron

I agree very much that integrating data from a variety of backends is
one of the promising areas for native XML DBMS's, and that ability to
handle semi-structured data is a key benefit.

Some native XML DBMS's are also well-suited to serve the role of a
middle-tier persistent transactional distributed cache.  Often such a
cache is also doing the kind of data integration you discussed above.

-- Dan