This article has shown how ANSI standard SQL can operate seamlessly on native XML at a hierarchical processing level. This achieves maximum integration while preserving and utilizing hierarchical semantics producing accurate hierarchical results. Alternatively, using stored procedures or other data access layers, as you suggested, requires additional coding and proprietary solutions. In addition, these: are not general purpose; do not support ad hoc use; require training; and do not produce the same quality hierarchical results.

As you pointed out, using a relational engine with its rowset still requires complex decomposing and reassembling the relational data to and from XML, but this does not take away from the above benefits, they are still valid and useful. For this very same reason, SQL?s relational engine performing hierarchically can be seamlessly replaced with a hierarchical engine, as described in the article. This avoids the complex processing of the rowset, and also avoids flattening the XML data and the resulting exploding Cartesian product result- the bandwidth problem you mentioned. This is shown in the bottom right portion of Figure 1.

Having knowledge of the final unified hierarchical structure being processed (naturally expressed in the expanded outer join views), means that the XML structured output can be generated non procedurally. I mentioned three cases as examples. The output can be specified as Element or Attribute centric, or by specifying the explicit typing in an SQL view avoiding the limitation issue you mentioned. In this way, variable result structures can automatically adapt to the specified output format and structure, offering additional flexibility over explicit (fixed)output mapping format methods.

/Mike

Hi Michael,
You describe a neat shorthand to querying hierarchic data with standard SQL.
Maybe I am jumping the gun here as this is just the 1st installment, but as far as I am concerned, the problem has never been the query/join mechanism (this can easily be achieved using stored procedures or other data access layer logic).
1. You still need to decompose and assemble the XML to and from relational tables.
2. You still need to describe how you want the data to be rendered as XML, unless it is all elements or all attributes. In most real-world scenarios, this method is too limiting. Unless relying on the database engine's proprietary rendering engine and mechanisms, you will still have to traverse the rowset and create the XML tags, including determining when a new parent has been reached (as the parent row is duplicated for each child = bandwidth issues unless performed locally)

Cheers,
Ola