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

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

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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]