XML Tangled in Its Knickers?
July 7, 2010
eHow’s “Disadvantages of an XML Database” is going to toss some tinder into the XML campers’ summer outing. The goslings and I love XML. We find that it is sufficiently complex to make some clients weep for joy when we perform some scripting magic. However, some organizations find XML to much hassle, preferring to deal with the oddities of Codd databases and the familiar costs of scaling technology with four decades strapped around its ample waist. What are the weaknesses the eHow write up spells out? Let me highlight three and you can navigate to the original write up for the full scoop.
The author, Tamara Wilhite, an eHow Contributing Writer, asserts that XML is a quasi loser due to:
- Performance issues. Hmmm. Interesting because I think Codd databases have some performance challenges as well. Perhaps some head to head performance metrics would bolster eHow’s argument. The assertion is offered without much foundation in my opinion.
- XML Database Conversion. Yep, extract, transform, and load is tough. The problem is that ETL and file conversion headaches are not limited to XML implementations. Like performance, there are a number of links in the conversion chain, and the write up does not tell me enough to feel comfortable with this assertion.
- Security. I am not sure if XML itself is a security problem. Perhaps some color would help me understand this point.
In short, eHow has generated a write up that will get clicks, but it won’t change my view of XML. Not enough meat for this spider food to be filling. Now who owns eHow? Is it Demand Media? Thoughts?
Stephen E Arnold, July 7, 2010
Freebie
Comments
2 Responses to “XML Tangled in Its Knickers?”
-
- Subscribe to Beyond Search
Feature archive
News archive
-
Stephen,
This article is ostensibly so weak — and the site behind it seemingly a linkbait scraper site — that I’m surprised you glorified it with your commentary.
Since you, I’ll take 30 seconds to respond on behalf of those with, uh, better information regarding XML databases.
1. “XML databases run slower.” On documents and/or semi-structured data, MarkLogic routinely beats RDBMSs by 10-1000x. The author has clearly never used a high-performance XML system nor does she appear to understand the difference between serialized XML, which is verbose, and tree-structured XML which is not.
2. ” XML searches are slow.” MarkLogic run as fast as any enterprise search engine when searching XML and faster than most databases. They don’t have to be.
3. “Difficulty with conversion.” Yes, XML is a different data model than the relational model. Converting either way from one to another poses problems. The author assumes you start everything relationally. But if you data is document-oriented or in an standard XML-based message format you are *already* in XML and thus converting it to another format to store relationally. You need to factor in both where you are and where you want to go.
4. XML systems can enforce schema if that’s what you want. One beauty, however, is that they typically don’t require you to. That’s helpful in dealing with the real world of messy data. More than helpful, in fact.
5. I don’t even understand the security argument, but I’d add that MarkLogic is in use at many top three-letter intelligence agencies. These people care a lot about security and have no problem with MarkLogic.
—–The original article states:
XML searches are slow
# XML has slower querying and searching functionality than other databases. The searches must sort through the text based information as well as the tags, which is slower than a search of only cell contents in a relational database. XML documents are built into databases via document trees, and the search must go through all branches of the tree before completing unless the search code is written to look for all related nodes and only search-related nodes.
—-I comment:
Nonsense !
Has the author never encountered XML indexes?