Re: [gnome-db] Multiple queries in report stuff
- From: Santi Camps <santi gnome-db org>
- To: Rodrigo Moya <rodrigo gnome-db org>
- Cc: GDA <gnome-db-list gnome org>
- Subject: Re: [gnome-db] Multiple queries in report stuff
- Date: 21 Jan 2003 19:46:15 +0000
> > 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
> > 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.
Anyway, in a lot of cases, the database tunning is not very good. 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.
> I think all this is up to the user of the report engine. We just have to
> make sure to allow multiple queries, and just let each user design
> his/her reports as they wish.
>
Yes, this should be the best. Let users to choose it
> > This has the handicap that is a new way to work, so it could be rare for
> > new users.
> >
> It is not. I've made a lot of reports with multiple queries (because it
> was impossible to get all in one big query). Unfortunately, I used a
> very bad tool for that (Prolifics' report designer www.prolifics.com),
> but fortunately that was a long time ago :-)
>
> > Do you think that this could be interesting, or it's better not to
> > reinvent the wheel and do the same that other engines ?
> >
> I would say it is not only interesting, but mandatory. I personally
> don't know too many report tools, but I would say that one that only
> allows simple queries is a handicapped one. I wouldn't have been able to
> use them, some years ago, for the reports I did.
>
Yes, I think so. But, for instance, in my job reports are done always with one big plain query + crystal reports. And, in some cases, big process should be done before in order to obtain the necessary plain data. It's horrible, so I was looking for a better way to work.
Then, I will try to implement this "nested queries", and will let also
the possibility to define groupheaders and groupfooters, and the users
will choose.
Cheers
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]