Re: [gnome-db] Multiple queries in report stuff

[Rodrigo Moya <rodrigo gnome-db org>]

On Tue, 2003-01-21 at 20:46, Santi Camps wrote:
> > > And then define groups in the report-engine.  In other words, we first
> > > obtain a big plain data and then we need to structure it.  Bank
> > > information appears once in the report but it should be in all the
> > > records of the recordset.  More memory and more data traffic that are
> > > not really needed.
> > >
> > what do you mean by more memory and data traffic? If the data is read
> > only once and stored in only one place, there is neither more memory nor
> > data traffic.
> > 
> I really don't know how the RDBMS and the providers work internally, but
> I was thinking that a field that is needed once (for instance, the bank
> name in the example) and appears in all the records of the recordset
> (miles or millions, it depends of the bank) should use more resources
> 
oh, yes, in that case, maybe it uses more resources, although, in many
cases, that would be less than the resources needed for running multiple
queries.

> > >   And, more of this, AFAIK a big joined query will be
> > > slower than some smaller queries in most database providers.
> > > 
> > this really depends on how the database is structured, and I would even
> > say that a well done (indexed and such) join query can be a lot quicker
> > than multiple smaller queries. This is specially true on RDBMS that, for
> > each query, have to parse, prepare and run it, operations that, for
> > Oracle for instance, take some time.
> > 
> 
> Yes, it should be truth.  I was comparing a big query with some smaller
> queries done in Oracle PL/SQL, where the parse should be done when the
> package is compiled.
> 
yes, in that case (and using prepared queries), it makes a lot of sense.

> Anyway, in a lot of cases, the database tunning is not very good.
>
yes. I remember, with that report engine I worked with, some reports
took more than 24 hours to generate. That was, of course, mainly the
database poor organization's fault.

>   For
> instance, in Oracle the order of the tables in the FROM clause could
> change the performance radically, and end-users normally don't know this
> kind of things. 
> 
yes, so that really depends on the user, which is the one that will
provide the queries. So this means that we really have to support single
and multiple queries.

cheers