Re: A good argument for XML

>select c.*, p.*
>from Projects p, Customers p
>where p.CustId=c.CustId
>
>right? BTW, where is hierarchy that XML nuts are so much talking about?

I think you are missing the point. Looking at the first example with the ugly XML prefixes, I think it would be safe to assume there are many Projects per Customer. So there are just two hierarchy levels on this example.

Reporting tools easily convert a table result like this into a hierarchy, where customer data can appear as a group header and project data as detail data. I doubt that anybody would like to present a report without a group header; assuming the header contains several fields, which is very common.

Now the following is a more dramatic example to illustrate the concept. This comes from an actual production report. I will just write out table names and indent to represent the hierarchy.

event

      participant
            agenda
            survey_headings
            ce_data
            faculty
            participant

OK there is more but I'll leave it there. Currently multiple statements are issued to the database for every node under the participant node. That is for every participant in a given event that makes for a lot of roundtrips to the server, and a lot of sparse code.

If I wanted to put them all on the same tabular result I would have to include 7 tables on the same FROM-CLAUSE. And maybe have a cross product between 5 tables. Somehow the reporting tool would decipher that? All this if we want to avoid a hierarchical output from the database where the final report output is clearly hierarchical.

I am still considering Jan Hidders suggestion. I just have not had enough time, I don't even know if what I looked at was XML/SQL v2 or v1.

Arturo Hernandez Received on Thu Jul 14 2005 - 22:59:36 CEST