Re: A good argument for XML

arthernan_at_hotmail.com wrote:
> >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,

Excuse me, but hierarchy with 2 levels is not really 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.

Nonsence. Displaying master-detail is an elementary application programming skill.

> 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

So you have several tables, and the join graph is a tree? Nothing special here.

> 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.

How big is the report. There is a natural limit on humans ability to digest information. When the data volume is big the front end is forced to present the information in a compact form. It would be either 1. A Report with Aggregated Data, or
2. Local Data view
By local view of the data I mean that there is no aggreagation, but simple data cutoff, e.g. only a page of the big list is shown, or only a node with its direct children is displayed. How do you want to present the information to the end user in your case and not overwhelm him?

Multiple roundtrips to a server are not a problem. I'm talking about basics of application programming performance. It is a problem when one of your queries return a list of data, and you issue a new query once per each row returned. Once again, if you designed your front-end correctly, such that your data display is not a humongous mess, then it's not hard to avoid this problem.

You are seriously dilluted if you think XML would deliver any scalable solution out of the box. By definition XML=slooooooow.

> 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.

Cross product smells design error. If you need data from 7 views, shoot 7 queries. An extra Roundtrip to a server itself is not an evil. It is bad when these trips are out of control, that is they are buried in some loop within application programming code. Also, the data from 7 queries sounds like a big volume of data to me. An end-user is not going to digest all this information in a second. The latency of user processing your report indicates that, perhaps, he can afford waiting a minute or two while the report is generating.

> 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.

What is "clearly hierarchical" about it? If your front-end uses a tree or tree table widget, then I will be convinced. Though, I don't see any use for XML in this case, either. Received on Fri Jul 15 2005 - 00:02:36 CEST