Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive

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

what's a better code design priciple?

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
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 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 (Subject line is ignored).

BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!

Boston Linux & Unix /