John Holmes wrote:
> Gesundheit
>>*if* that was on Oracle *and* the table was big you'd notice that your
>>performance goes down. Don't ask me why. And I never checked it on
>>MySql. But watch out for betweens. Check them.
> Yes, good point. I don't know if it matters in MySQL either, but always
> test your queries and see which is faster. EXPLAIN may come in handy
> here. I don't see why it would be different, it seems like both would be
> interpreted the same...

Most PHP apps underlying storage simply does not reach the dimensions 
needed for the difference to show up (that is, when rows come in hundred 
of thousands and you have a fairly good normalized data structure, say 
at least in the third form). Yest if you don't normalize data you might 
see it degrade when you are just in the pale realm of thousands.

For what I could make out of it myself, it has to do with the fact that 
an SQL macro instruction (if you pardon the use of the "macro" term in 
this context) needs to be translated to some set of "and...or" clauses 
before the engine can actually execute it. Some engine does the 
translation on a "per row" basis, which is why they can end-up killing 
your performance.

That's just my own fantasy about it, no such assertion is in *any* docs 
that I saw. But if it was done just once the size of your query set 
should be irrilevant to performance, methinks.



LoRd, CaN yOu HeAr Me, LiKe I'm HeArInG yOu?
lOrD i'M sHiNiNg...
YoU kNoW I AlMoSt LoSt My MiNd, BuT nOw I'm HoMe AnD fReE
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is
tHe TeSt, YeS iT iS
ThE tEsT, yEs It Is.......

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to