There are a lot of applications that benefit from native XML storage in a database. Here are some examples: http://www-01.ibm.com/software/data/db2/customers/ . Of course those customer statements are somewhat biased coming through IBM, but still fairly accurate and realistic.
Storing XML as a string is really not very useful since you can't query into the document contents. You also can't create indexes on particular elements or attributes for fast access.
Microsoft has a good explanation of why it isn't necessarily appropriate to store XML structures in a conventional RDBMS. I'll quote it here:
"The XML data model has characteristics that make it very hard if not practically impossible to map to the relational data model. XML data has a hierarchical structure that may be recursive; relational databases provide weak support for hierarchical data (modeled as foreign key relationships). Document order is an inherent property of XML instances and must be preserved in query results. This is in contrast with relational data, which is unordered; order must be enforced with additional ordering columns. Re-assembling the result during querying is costly for realistic XML schemas that decompose the XML data into a large number of tables."
Ok, seriously? You're asking an RDBMS to index into XML data you've shoved into a column?
Quoting Microsoft & IBM on database design is like quoting GM & Chrysler on vehicle design. All are years behind and focused on an under-informed and declining customer base.
2 things:
1. Postgres supports both Regular Expressions and indexing on expressions. If you can't index your table on a regex expression, you are probably doing something wrong.
2. Reconstructing full XML documents from a single column based on a query is a lazy anti-pattern. Either a) store the document in a way that it can be retrieved on demand, or b) structure the data and the query in a way that is performant. Jamming a verbose textual representation of data into a single column of a table and then demanding performance is a fundamental misunderstanding and misuse of an RDBMS table.
Apparently you don't understand how it actually works. At least in the case of DB2, the database engine doesn't store a "verbose textual representation" of XML documents. It breaks them down into a more efficient internal binary format that still preserves the structure.
I deal with complex XML documents that go a dozen or more levels deep. It would certainly be possible to represent that data in a relational structure. But then to query based on the value of a deeply nested element would require a large number of table joins. Keeping everything in a single XML column is much simpler and faster, since the specific inner element values can be indexed.
Hierarchical databases have been around for years, and actually predate relational databases. XML databases are just a specialization of hierarchical databases. Some applications are a better fit for the relational model and some are a better fit for the hierarchical model. With hybrid databases you get the best of both worlds and can choose the right tool for the job.
"Apparently you don't understand how it actually works."
Man, nope. No disrespect but if you are regularly querying 12 levels deep into an XML file you have stored in your database then IMO you are almost certainly doing something horribly, horribly wrong.
Comments
There are a lot of applications that benefit from native XML storage in a database. Here are some examples: http://www-01.ibm.com/software/data/db2/customers/ . Of course those customer statements are somewhat biased coming through IBM, but still fairly accurate and realistic.
Storing XML as a string is really not very useful since you can't query into the document contents. You also can't create indexes on particular elements or attributes for fast access.
Microsoft has a good explanation of why it isn't necessarily appropriate to store XML structures in a conventional RDBMS. I'll quote it here:
"The XML data model has characteristics that make it very hard if not practically impossible to map to the relational data model. XML data has a hierarchical structure that may be recursive; relational databases provide weak support for hierarchical data (modeled as foreign key relationships). Document order is an inherent property of XML instances and must be preserved in query results. This is in contrast with relational data, which is unordered; order must be enforced with additional ordering columns. Re-assembling the result during querying is costly for realistic XML schemas that decompose the XML data into a large number of tables."
http://msdn.microsoft.com/en-us/library/ms345117(SQL.90).asp...
Ok, seriously? You're asking an RDBMS to index into XML data you've shoved into a column?
Quoting Microsoft & IBM on database design is like quoting GM & Chrysler on vehicle design. All are years behind and focused on an under-informed and declining customer base.
2 things:
1. Postgres supports both Regular Expressions and indexing on expressions. If you can't index your table on a regex expression, you are probably doing something wrong.
2. Reconstructing full XML documents from a single column based on a query is a lazy anti-pattern. Either a) store the document in a way that it can be retrieved on demand, or b) structure the data and the query in a way that is performant. Jamming a verbose textual representation of data into a single column of a table and then demanding performance is a fundamental misunderstanding and misuse of an RDBMS table.
Apparently you don't understand how it actually works. At least in the case of DB2, the database engine doesn't store a "verbose textual representation" of XML documents. It breaks them down into a more efficient internal binary format that still preserves the structure.
I deal with complex XML documents that go a dozen or more levels deep. It would certainly be possible to represent that data in a relational structure. But then to query based on the value of a deeply nested element would require a large number of table joins. Keeping everything in a single XML column is much simpler and faster, since the specific inner element values can be indexed.
Hierarchical databases have been around for years, and actually predate relational databases. XML databases are just a specialization of hierarchical databases. Some applications are a better fit for the relational model and some are a better fit for the hierarchical model. With hybrid databases you get the best of both worlds and can choose the right tool for the job.
"Apparently you don't understand how it actually works."
Man, nope. No disrespect but if you are regularly querying 12 levels deep into an XML file you have stored in your database then IMO you are almost certainly doing something horribly, horribly wrong.
Apparently you've never worked with complex healthcare data. If you can figure out a simpler way be sure to let us know.