Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML Database Decision Tree?
 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. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
