What are the advantages and disadvantages of using an XML database?

Question

I came across a CMS known as GetSimple. It uses XML to store all of its internal data. In a sense, it uses XML as a database. Now someone can explain to me the advantages and disadvantages of using XML as a database.

Thanks at Advance. Tanmoy

Answer 1

Using XML as your database will work fine as long as your datasets remain relatively small. Having risen, he can all fit in his memory and stay there comfortably. Once your data has grown to such an extent that it does not fit into memory, you are likely to begin to see a serious degradation in performance.

Answer 2

Some information cited on this site:

If your application needs to move data between enterprises, XML is a good solution. XML allows you to send data over the Internet and through firewalls using the standard HTTP protocol. XML is also a good choice if your application needs to move data between hardware or software platforms (OSs). XML does not apply to specific machines or operating systems . Finally, XML is a good choice if you just want your application or data source to be reliable, even if the data schema has changed . XML allows your application to expand because you access XML-formatted data using element and attribute names instead of offsets that structured programming languages ​​use. Note that using element names and attributes to access data in XML is similar to accessing fields by name in a SQL Server table. If you have one or more of these application requirements, then XML is a good solution for you.

Then you need to determine the best place to generate or consume XML in your application, which is an important decision since using XML requires processing overhead . These overheads appear differently depending on whether you consume or create XML. For XML users, you need a minimal method for parsing XML. You will probably also need an object model to access the analyzed data. For XML producers, converting native data formats to XML is an overhead. At an intermediate level, processing overhead is critical. If your mid-tier program manages, performs calculations, or reformat the data, and your database is inside a firewall, XML should not be your first choice . In this case, the request to obtain a normal set of results from the database and the use of traditional data access methods to perform application processing will be more efficient. When processing is complete, a mid-tier application can generate XML output. Using traditional data access methods avoids the overhead of creating XML in a database, as well as the overhead of parsing XML and building an object model at an average level. The only potential benefit of creating mid-level XML is that you can freely link your mid-tier application and your database, but the cost is significant.

Now apply these usage rules to the scenario that you describe in your question. You don't seem to have a requirement to move data between enterprises, over the Internet or through firewalls. So, unless you are trying to make your applications more extensible, XML is not a good choice for your scenario . Traditional data access technologies will meet your needs. But to demonstrate the value of XML, suppose you need to make your application extensible. You can upgrade to SQL Server 2000 and use the native XML support. This is your best option as it provides maximum flexibility. If you must access your data from SQL Server 7.0 or 6.5, check out SQL Server XML Technology Preview Technology http://msdn.microsoft.com/downloads/samples/internet/xml/sqlxml/default.asp . This preview provides functionality similar to XML support in SQL Server 2000, but the preview works with SQL Server 7.0 and 6.5. (For information on the differences between SQL Server 2000 XML integration and a preview of Microsoft XML technology, see Bob Beauchemin, XML Files, September 2000.)

Answer 3

An overview of found networks this article on XML.com

Input: "After a recent XML-DEV discussion on how to choose the most appropriate database for your XML application, XML-Deviant displays indicators that help you get closer to the solution."

The article talks about the difference between "data" and "document."

Answer 4

In fact, XML documents are already databases, no matter what you do with DOM, SAX, Pull or VTD-XML, you still have to do it after saving to the database ... this is a more or less promising change in my view

Answer 5

I think this also depends on the complexity of your queries. If you write XPath queries comfortably enough, then even if you have to query data for several “dimensions”, you are still left with XPath code that is not terrible enough.

However, if you are talking about a data model that would require joining across 3 or 4 tables in SQL, you are probably close to the point at which XPath scales so much. I can’t say how well this works with other query languages ​​such as XQuery or XLinq - perhaps the trade-off is somewhere else.

Answer 6

Also, see http://www.joelonsoftware.com/articles/fog0000000319.html for an explanation of why "you cannot quickly implement the SQL SELECT author FROM books statement when your data is stored in XML."

("fast" is the key word here)