������!
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
