Conceptual Question about Queries

  • Thread starter Thread starter Jack G
  • Start date Start date
J

Jack G

I am about to add quite a few new Forms and Reports to my database, and I
don't want to erode (what seems to me to be) the snappy performance I have
now. Here's my question: Is it generally better to have a lot of queries
each of which specifically addresses the needs of the form or report it
serves (sorting, filtering and only including needed fields), or is better
to build fewer queries and make them all-purpose queries which include all
the fields you might ever need and lets the form or report do the sorting
and filtering?

Jack
 
Hi, Jack:
I probably ought to keep my mouth shut and just listen -- BUT:
I've tried it both ways over a WAN and it seems to me that if you have a lot
of little queries you are bedevilled with keeping track of what goes where
(if your naming convention is solid and consistent as mine is not then this
might not be a big deal). I tend to use a "Hairy Query" that pretty much
includes everything I can think of (in addition to a bunch of little ones
that I have to keep track of) and I have to say that just executing queries
seems pretty quick either way. The big delay seems to come with reports that
have multiple grouping levels. I might be wrong, but I think that would be
the case no matter the size of the query. I frequently find myself
reinventing queries in the case of the little ones. If you are not stuck
with using a WAN (and you shouldn't be) then I doubt the query execution time
will matter a lot unless you have an awful lot of records. For the purpose
of comparison, my backend is about 10 megs after compacting and the round
trip from our office to the server and back is about 150 miles 6 concurrent
users, 3 of which use Citrix, 2 use the WAN due to printer incompatibility
problems (being solved now, hopefully), 1 using the WAN because she is a true
follower of Ned Ludd.
HTH
Mike
 
Back
Top