On Wed, July 6, 2005 4:21 pm, Richard Davey said: > RL> And in the case case where a row is returned, the id will probably > RL> be the same number of bytes as a count(*): a 32-bit integer. > > Say you've got user number 20,000 in a table. He only exists once, so > count() only returns 1. Bring back the ID and you'll get sent a value > of 20000. I would be shocked if, on a byte for byte transfer level, > there was no difference between the two. Once it's in memory at the > other end, sure they'll both most likely become longs anyway. You've just made my point. The actual data tuple returned in both cases is a long, if there is a user to match. But the data returned, for SELECT id, when NO rows are there is, well, nothing. Not even a long. For count(*) there is an "extra" long being returned, in the tuple, that is already available in num_rows() anyway. > When it comes down to milliseconds, I doubt there is much in it to be > honest. Certainly something hard (and I'm sure you'd agree useless) to > quantify. But hey, we're being pedantic here, yes? :) At the end of > the day it just seems like a coding preference to me. After all, I > don't want the users ID number, I want to know how many users exist > matching that username (i.e. I want a count of them), so that's what > I've directly asked MySQL for. 99 times out of a hundred, the very next thing your application is gonna do is get their ID, maybe their name, maybe their email, etc, so you can do something more interesting in your script than just know they exist. Better to plan out your application and figure out what data you need on most every page, and write one query to get that data, than to have the un-coordinated mass of queries to all hit the same table, the same index, and the same user data. I can't count how many times I see junk like: $db = new dbi_thingie_the_programmer_clearly_doesnt_understand(); $id = $db->get_id(); $name = $db->get_name($id); $address = $db->get_address($id); . . . Bam! 10 hits to the database on every damn page. Ugh. Only the fact that PHP and MySQL are so blazing fast allows this kind of Bad Coding to exist. Some days I think newbies should be forced to use IBM PC Jrs with 16K RAM and a 60 Meg hard drive (or whatever) just so they learn to code... :-) -- Like Music? http://l-i-e.com/artists.htm -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
