But, it is important to point out that subselects are usually not as efficient as joins. From what I understand it is better to do a join when you can.
Another big reason for subselects is that it doesn't fragment your application all over the place. It keeps everything in one tidy place. While MySQL is usually sufficient for most people's needs, it often requires that your database logic get mixed up with your application layer, muddling the neat boundary that I believe should exist between the application and database layer.
Carl
Andrew Jorgensen wrote:
On Mon, 2004-01-05 at 20:29, Corey Edwards wrote:
On Mon, 2004-01-05 at 19:14, Daniel Crookston wrote:
Ewww, sub-selects. Not a very efficient use of the DB, is it? I was under
the impression that it's just as fast (with MySQL at least) to just do the
sub-select yourself in the code instead of relying on the database to do it.
That sounds like a dubious claim to me. I'd be interested in some hard numbers to back it up. I can't see how adding network latency, memory copies and data transfer can possibly speed up an algorithm. Well I can, but this is hardly [EMAIL PROTECTED]
Fact is sometimes subselects are an appropriate construct and a query
will benefit from a server which supports them.
More importantly (IMHO) subselects are a more elegant way to express your query. It's probably true that you can convert almost any subselect to a left outer join, but that's just not an elegant way to do it, nor is it intuitive.
BTW: If any subselect can be expressed as a join why can't the DB server just do that conversion for me?
____________________
BYU Unix Users Group http://uug.byu.edu/ ___________________________________________________________________
List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list
smime.p7s
Description: S/MIME Cryptographic Signature
____________________ BYU Unix Users Group http://uug.byu.edu/ ___________________________________________________________________ List Info: http://uug.byu.edu/cgi-bin/mailman/listinfo/uug-list
