On Apr 11, 5:08 am, "lyle fairfield" <lylef...@yahoo .cawrote:
Sometimes yes, sometimes no. Generally I do avoid NOT IN but
sometimes I'm surprised to find it works rather quickly. If you find
NOT IN is slow, try rewriting as an outer join or vice versa and
figure out which works best.
Bruce
On Fri, 11 Apr 2008 00:09:48 -0400, Tom van Stiphout
>
<no.spam.tom7.. .@cox.netwrote:
>
>
Do you think a NOT IN operator on a sub-query might be very slow?
>
OT: I'm experimenting with News Clients; this is Opera's.
>
<no.spam.tom7.. .@cox.netwrote:
On Thu, 10 Apr 2008 12:36:56 -0700 (PDT), Wayne
<cqdigi...@volc anomail.comwrot e:
<cqdigi...@volc anomail.comwrot e:
I can't think of the exact SQL right now, but I have a feeling one
should be able to come up with it: use a cartesian product query
between the table with timeslots and the appointments table to get all
possible timeslots for all days. Then do a "WHERE NOT IN (select ..."
query to find those slots that are not already taken.
should be able to come up with it: use a cartesian product query
between the table with timeslots and the appointments table to get all
possible timeslots for all days. Then do a "WHERE NOT IN (select ..."
query to find those slots that are not already taken.
Do you think a NOT IN operator on a sub-query might be very slow?
>
OT: I'm experimenting with News Clients; this is Opera's.
sometimes I'm surprised to find it works rather quickly. If you find
NOT IN is slow, try rewriting as an outer join or vice versa and
figure out which works best.
Bruce