Slashdot Mirror

← Back to Stories (view on slashdot.org)

Do XML-based Databases Live Up to the Hype?

Posted by Cliff on from the successful-implementations-in-practice dept.

douthitb asks: "I have recently started work as a contractor with a company developing/improving an application for exchanging large amounts of data. The current solution exchanges data via XML, but the data itself is stored in a SQL Server database. There is a concern about the overhead involved with wrapping and unwrapping the XML to get the data in and out of a relational database. The proposed solution is to use Tamino, an XML-based database. Neither I nor any of the other developers have any experience with Tamino, but the desired result is to remove the bottleneck of converting the XML back and forth. Does anyone have experience using Tamino (or any other XML-based database)? What benefits and/or difficulties did you have in using an XML database, as opposed to its relational counterpart? How large of a learning curve should be expected with a product like this? Do XML databases really live up to the hype? A similar topic was discussed on Slashdot way back when, so I was hoping to get some more up-to-date feedback on the subject." "Sales reps from Software AG, the makers of Tamino, were brought in to discuss the benefits of their product with us. They, of course, presented Tamino as the end all, cure all database system (it will even clear your acne and make you popular with the girls!). The management of the company I'm contracting with were basically eating out of the sales reps' hands, without asking any of the "tough" questions about what the product can do; I was less convinced. Doing some initial searching on the Internet, I have had trouble finding much information about Tamino outside of the Software AG website."

5 of 105 comments (clear)

  1. Oracle and XSQL by Rich · · Score: 4, Interesting

    Oracle and XSQL/XSLT works fine for the database we use at work. The overhead of wrapping and unwrapping the data doesn't seem to be any problem.

    1. Re:Oracle and XSQL by Wabbit+Wabbit · · Score: 3, Interesting

      The overhead of wrapping and unwrapping the data doesn't seem to be any problem.

      Yeah, but how much data? And how many calls/second?

      A few years ago I worked on a day trading system that talked to a SQL Server database and we were going to use XML to wrap the data but found that it did add significant time to the commits, and in that business time was $$$ so we left it out. (and yes, we spooled commits out of a separate thread, etc. etc. but don't ask; it was a complicated architecture that I was saddled with, and there was still some db code in the core codebase).

      --
      Nothing is inexplicable; only unexplained -Tom Baker, Doctor Who
  2. I agree by Tangurena · · Score: 4, Interesting
    Having worked with a business partner who claimed total XMLosity in their database, I had to rework the parser almost every time we got a data feed from them. Their idea of the data model changed from day to day. Even when we sent nailed down, will never change specs for the structure. They really didn't like the idea that I tossed the raw XML into a memo field every time my components received a message, so when there were nasty fingerpointing meetings, I could drum up a simple SELECT statement and show everyone what was changing each and every week.

    XML is kinda nice for some things, and really rotten for some things. Please do yourself a favor and sit down and try to decide what problem you are trying to solve. XML really stinks when it comes to sets: something that SQL based databses excel at.

    I think that with the XML fetish we have these days, that we are reverting to the preSQL days of CODASYL or IMS (pre 1980s for those of you young'uns).

  3. I've used Tamino and here's my story by snowtigger · · Score: 5, Interesting

    A few years back, I was brought in to a small company to build their new software on top of the Tamino DB. XML was "the way of the future" and we were asked to use it as much as we could. Software AG promised that everything would be easy to program and that their software functioned perfectly. Software AG's sales rep used the fact that Tamino was used in production by (insert major national company here) as a major selling argument. I later found out from a friend working there that they had only evaluated Tamino, found it useless, and never used it in production.

    Well, we did finish the software on time, but it was a complete nightmare. Software AG hardly gave us any straight answers (even though they charged big $ for customer support).

    Tamino itself was missing a lot of features and seemed designed as a system for storing documents, totally lacking traditional database qualities (uniqueness, reliability, scalability, ...) We couldn't even get a reliable unique key from the database. The id we did get "could change" if we were to backup and restore the database. Tamino also scaled very badly with simple queries taking up to a minute on the fastest PC we could buy.

    Needless to say, the software was thrown away and rebuilt with a reliable SQL database.

    I would strongly discourage anyone from bilding an application on top of an xml database, especially Tamino. If you really want to build your application on top of an xml database, I would seriously ask myself why and what difference it would make. Also, if you really need an xml interface, choose an ordinary sql db that has a xml plugin.

  4. Relational-friendly text alternative by Tablizer · · Score: 3, Interesting

    In case anybody is interested, here are some suggestions for making a more relational-friendly alternative to XML, Here is a wiki topic.

    Another potential problem is that existing RDBMS tend to be strong-typed. However, "dynamic relational" is not out of the question. Just because current RDBMS are strong-typed and have "static schemas" does not mean that is the only way to do it. There is a distinction between limits of implementations and limits of relational theory.

    --
    Table-ized A.I.