Re: A good argument for XML

arthernan@xxxxxxxxxxx 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.

.

Relevant Pages

  • Re: Nearest Common Ancestor Report (XDb1s $1000 Challenge)
    ... Your original post didn't point out that classes may form a hierarchy as ... it's XDb1 that can't display the names this way. ... The relational model allows for the natural key to be used as a table's ... RM's report is more complete. ...
    (comp.object)
  • Re: Nearest Common Ancestor Report (XDb1s $1000 Challenge)
    ... You implemented the ability to generate a report for the class/type ... version is unable to generate the ANC report for the class/type hierarchy: ... Many people of great fame have published about normalization ... Since the source code of XDb1 is not public, there's no way that I (or any ...
    (comp.object)
  • Re: Nearest Common Ancestor Report (XDb1s $1000 Challenge)
    ... I just saw five further posts by you about the three-thing hierarchy. ... >passing the parameters correctly to the report generator (because the ... >the class hierarchy report, the db has an entry for each symbol. ...
    (comp.object)
  • Re: Nearest Common Ancestor Report (XDb1s $1000 Challenge)
    ... It does not model the class hierarchy in the appropriate table thus ... It does not model a way to normalize names of things. ... has duplicate data which needs to be replaced with proper refs ... RM's report is more complete. ...
    (comp.object)
  • Re: Nearest Common Ancestor Report (XDb1s $1000 Challenge)
    ... See below measurements for a Larger Report ... created from a 400 Goat Hierarchy ... With Sql Server, for the first run, I started with 10 MB db. ... memory useage started at 25,480 MB and was continoulsy growing, ...
    (comp.object)
Loading