Storing XML data in database - many tables vs dumping xml in a column

Question

I want to store an xml that I receive in my java web service. Reports would be run every 5 mins to pull some data in the xml elements.

I thought of two approaches to solve this problem.

1. Create multiple tables in the database to capture the xml data. Basically each element will have its own column in the database.

2. Dump the whole xml in a column that can store xml data. For reporting purposes parse the value in the query itself.

Which of the above approaches is better, particularly in terms of performance? This is critical since reports will be generated in very high frequency (every 5 mins).

The xml schema is pretty complicated and not a simple one.

Answer 1

If data is going to be written once and queried many times, it will almost certainly be more efficient to parse the XML document once, store the data in a proper relational schema, and query the relational schema. Parsing XML is not cheap so the overhead of parsing potentially multiple XML documents every 5 minutes could be substantial.

Of course, as will all performance questions, your mileage may vary so it may be worth testing. If you are using Oracle 11.2 and you store the data as binary XML (in which case it is stored after being parsed) and you create appropriate XMLIndexes on the XMLTypes you are storing, the performance penalty for leaving the data in the XML document may be quite small. It should still be slower than a proper relational structure but the difference may not be meaningful to you.

Personally, I'd prefer the relational storage approach in general even ignoring the performance issues because it makes it easier for others to interact with the data. There are far more developers that can write decent SQL than can write decent XPath expressions and there are far more query tools that can generate reports off of relational tables than can generate reports off of XML stored in a database.