Re: A good argument for XML
Date: Thu, 14 Jul 2005 16:08:15 -0700
Message-ID: <dmrdd1p5atteqkivmn301kblcl531ucsaa_at_4ax.com>
On 14 Jul 2005 13:59:36 -0700, arthernan_at_hotmail.com wrote:
[snip]
>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
So?
>product between 5 tables. Somehow the reporting tool would decipher
>that? All this if we want to avoid a hierarchical output from the
Easily. Create a view.
>database where the final report output is clearly hierarchical.
And what about another "hierarchical report" with a different set of joins? You are stuck with your first hierarchy.
invoice
invoice line
product
is fine for printing invoices. It is not so good when you want to know what invoices a given product appears in. I had that exact problem in an accounting system. I ended up having to write a program to grovel through the batches.
The beauty of relationally-organised data is that many more questions can be easily answered.
[snip]
Sincerely,
Gene Wirchenko Received on Fri Jul 15 2005 - 01:08:15 CEST