Slashdot Mirror
Do XML-based Databases Live Up to the Hype?
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."
Just like XML itself. Seriously, just use a decent RDBMS.
There are a few things to bear in mind when using RDBMS:
(1) NULLS are evil. Don't allow them.
(2) Duplicate rows make no sense. God alone knows why so many databases tolerate them.
(3) each "row" is a predicate. The "least worst" mapping in an RDBMS is table-per-object-instance, with each row being a snapshot of the state of an object at a given time. As an optimisation you can place different objects of the same class (it is worth noting that many OO experts regard classes as a mere optimisation too) in the one table, but if you catch yourself thinking "a row is an instance", your RDBMSObject mapping is almost certainly WRONG.
(4) Don't be afraid to mutate you schema. RDBMS are supposed to be living (figuratively) multiuser systems. If you have a DBA saying "the schemas must remain fixed", he's a control-freak nazi and you're better off without him. Users should be allowed create and delete tables and views willy-nilly. The worst thing to happen to RDBMS were DBAs, who have pissing contests about getting every ounce of performance out of Oracle, while totally destroying sytem flexibility and utility. Imagine a SysAdmin forbidding you from changing the subdirectory layout of your home directory! Yet people put up with that sort of crap from DBAs all the time. The best and most successful business I ever worked for (shame it was only a short term contract in my case) gave enterprise-level RDBMS as a service to the desktop, just like home directories or an office suite i.e. every user had a personal database for whatever the hell they wanted on a backed up central server.
In .NET you go to the Server explorer and choose your database and table from a tree control and drag the tables directly to a canvas to design a dataset. You can then define releations. Then, you drag a data adapter to a web page or windows form, type the sql and visually associate it with the data set. Its done all visually except for the sql and even that can be generated.