I've used XQuery in Oracle quite a bit and I wouldn't exactly say it isn't an issue. My use case is weird - thousands of xml files that have to be uploaded and

I've used XQuery in Oracle quite a bit and I wouldn't exactly say it isn't an issue. My use case is weird - thousands of xml files that have to be uploaded and then queryable/joinable to an existing relational model. We found that the only way to pull this off with decent performance is to pull out the "most queried" xml nodes and node values in materialized views with indexes. I've also experimented with nested sets, which work very well for our situation. Regardless of how we store the XML and query/join it to our relational data, I continue to struggle with a decently performing "pivot" step. The XML we have is really messy, with each independent XML tree having lots of 1 . . N nodes for a specific element. This makes "flattening" the XML out with relational data messy. If it was only a single XML tree, it wouldn't be a big deal. But our user queries tend to hit many of the XML trees and we wind up with lots of "empty" node elements in the total result set. Plus, node order from our XML is extremely important to users, so node A containing node B containing node C with node order represented by depth in the tree must now swap over to left-to-right order and preserve the relationships between A->B->C. It's actually fun . . . the whole ordering, "pivot" mess is really a presentation layer thing, our users want all this cranked out in grids with Excel export capability. From a pure programmatic standpoint, cranking on the combined XML and relational data model is not difficult.