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

[XML Everywhere <host@xmleverywhere.com>]

Has this thread addressed ISVs yet?  I mean the
people who sell traditional software.

If you have a product that uses a non-standard database
engine in non-trivial ways, it makes it much harder 
to make a sale.  If native XML databases can
hide in the background without any need for 
backups or tuning or maintenance or legacy
integration or data extraction, their acceptance
would be a no-brainer.  But for most non-trivial
software, these issues almost always present their ugly
heads.  Some customers are smart enough to
realize this up front, some aren't.  The bigger
customers tend to be more savvy about their data,
but by no means all of them.

Most IT shops have standardized on either Oracle
or SQL Server or DB2.  This means that most software
packages must support all three, so anything specific
to one vendor (e.g., SQL Server 2000's XML
support) is pretty much useless.

In several instances, the native XML vendors have
spruced up and repackaged their failed
object-oriented databases from the 1980's.  Native
XML databases will fail to be accepted by major IT
shops for the same reasons why OODBMs
packages failed:  They're not relational.  They
lack tools.  They are hard to troubleshoot.  They
are expensive.  Support is impossible to get.
Support is expensive.  People who understand
the technology are expensive.

Some native XML vendors really do have new technology
written from the ground up.  Bluntly, it doesn't matter.
Instead of putting lipstick on a pig, it's just a new pig
made from scratch.  (no offense to pigs)

You can never avoid the platform.  The programming
language and the target platform affect ythe
decision as well.  JDBC-based solutions seem to be
good at straddling the divide between Oracle,
SQL Server, and DB2.  If you can get away with
only shipping on Windows, which is becoming
suicide more and more, ADO is still not bad,
but it's painful.  

As for myself, I do both.  I use
ADO when I can control the platform and
JDBC when I can't.  Believe it or not, there
are still customers out there who don't want
to (or don't feel like they should have to) 
buy anything that's written in Java.  Don't
ask me why.  Some people hate Microsoft
and some people hate Sun.  Can't we all
just love one another?

There are packages that stream xml in and out
of RDBMSs.  Some prompt you to type in
SQL statements, some force you to write
(I mean they "support") stored procedures,
some have cool mapping tools.  I have not
found anything decent yet, although they all
claim to be perfect.  Most of them don't
even attempt "updategrams" and most of those
that do are primitive at best and don't
deal well with primary and forign key
relationships.  Some are free and
some are quite expensive.  Again, I have
yet to use a product that lives up to its
claims or is worth paying money for.

To their credit, Microsoft built the best solution.
But, thanks to Bill, it only works on SQL
Server 2000 and thus Windows which is a pity.
If Bill let SQL Server run on Linux and
Solaris, things would be more interesting.
But apparently, Bill isn't as smart
as they said he was, or maybe he is
so diabolically smart that the success of
his closed strategy will be obvious 100 years 
from now.

If all you do is write ASP or web apps, then nobody 
cares what technology you use.  And so the decision making
process becomes a lot more difficult.  There's a lot
of junk out there.  There's a lot of interesting 
technology out there.  If you have time
to waste evaluating new technologies, you will waste it.

Meanwhile the people with deadlines and customers
generally choose RDBMSs.  And they generally
do those grungy things like define RDBMS schema
and write stored procedures.  Most of the time
they don't need XML at all.  Sometimes XML
is just a solution looking for a problem.

Important data matters a lot.  It is as worth-while
to define an RDBMS schema as it is to define
an XML schema.  And let's face it, RDBMS
schema is far more understood and proven than
any corresponding XML technology.  It would be nice to
wave a magic wand and deem some native xml
database out there as the "industry standard" and
have IT shops everywhere instantly convert their
data to it.  But that is never going to happen.

XML is very powerful for spreading data across
applications.  It is mildly useful for moving 
data into databases if you know what you're doing.
XML is almost useless for transforming data because
XSLT was not meant for large data sets and
SAX requires non-trivial programming skills.

Native XML databases have no chance
until schema, transactions, query, extraction, bulk load, 
and data transformation are all reasonably
standardized.   Which _isn't_ going to happen 
in our lifetimes, unless you're a ten year old.

Perhaps the world won't
even need a "native XML database".  
The world needs better, cheaper,
standard tools for dealing with large quantities
of data.  I do believe with total certainly
that XML will be part of the solution.  But
XML will not be the entire solution for quite
some time to come, if ever.  There is no vendor
out there who is ready to fill the shoes
of an Oracle or a SQL Server or a DB2.
The engineers of xml databases
are, or should be, relieved that they are not on 
the critical path for the world's data 
needs.

Today, native XML databases are useful for
applications in which RDBMSs are either
unnecessary, or simply don't work.
In other words,  the file system would do 
just fine.  XML databases offer many needed 
features above and beyond the file system.  
Therefore, I don't discredit native XML databases
entirely.  I do believe they have a place in 
content-management systems and the like.
But native XML DBMSs are
not appropriate for most ISVs, at least 
for the foreseeable future.