Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
Tough call. In general, the higher the level of abstraction at which optimization can be performed, the more effective the optimization. In other words, a human programmer who understands the overall goal has the potential to be more effective at optimization than a compiler or a processing engine, often by orders of magnitude. On the other hand, issuing multiple queries to a database can often produce a lot of extra overhead in terms of locking and in treating intermediate results, so you are usually going to be better off letting the SQL engine do internal optimizations. If the complicated query causes a lot of operations which generate intermediate data that just gets thrown away, however, then a chain of simpler queries might make more sense. Ultimately, the only way to know is to measure both ways. Even this is no absolute assurance, since your benchmark might be affected by the size of the database, the number of running indices, and other variable factors. -- Mike On 2000-05-30 at 14:16 -0400, Christoph Doerbeck A242369 wrote: > a) use multiple simple SQL queries requiring additional code > b) increase SQL complexibilty, use one query and reduce code size - 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).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |