what's a better code design priciple?

[dkatz at kenan.com (Daniel Katz)]

Christoph Doerbeck A242369 wrote:
> 
> Hey folks,
> 
> I am at a cross roads in the development of a little application.
> What's better in the interest of performance and (more importantly) code
> maintainability?
> 
>         a) use multiple simple SQL queries requiring additional code
>         b) increase SQL complexibilty, use one query and reduce code size
> 
> Comments?  Obviously it's tough to gauge the best solution without knowing
> my design in detail, but I was wondering if there were some hacker
> standards I should go by...
> 

The up side of multiple small queries:  easy to understand, simple to
cache
The down side of multiple small queries:  tends to lead to "code joins"
(i.e., doing 2 or more simple selects and then doing the join in the
program with loops)

The up side of one big query:  use the SQL optimizer to do query well
The down side of one big query:  harder to understand and modify

I would say that the basic approach should be to "Use the database for
what it's good at."  If you are doing table joins and subselects, these
should almost certainly be done in the database rather than in the code,
since the database query optimizer is *much* better at using indices,
distribution statistics, and relational logic theorems to speed up a
query than you are.  If you're just selecting independent information
from a bunch of tables, small queries which match the program logic make
more sense (at least to me).

Sorry if this seems obvious or pedantic, but as you say, without knowing
your exact problem it's hard to be precise...

Dan

Dan Katz
-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).