469,271 Members | 1,776 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,271 developers. It's quick & easy.

Negative SELECT in mysql?

How does one retrieve the rows in a select statement that DONT match the
select.

select CarIndex FROM DealerCatalog, BigCatalog WHERE
DealerCatalog.CarIndex=BigCatalog.CarIndex

finds all the cars in the dealer catalog that are in the bigger distributor
catalog.

How do I do the opposite in a single sql statement i.e. all the dealer cars
that AREN'T in the big distributor catalog?

Is there a negative Select?

Jul 17 '05 #1
12 13775
kaptain kernel wrote:

How does one retrieve the rows in a select statement that DONT match the
select.

select CarIndex FROM DealerCatalog, BigCatalog WHERE
DealerCatalog.CarIndex=BigCatalog.CarIndex

finds all the cars in the dealer catalog that are in the bigger distributor
catalog.

How do I do the opposite in a single sql statement i.e. all the dealer cars
that AREN'T in the big distributor catalog?

Is there a negative Select?


select CarIndex FROM DealerCatalog, BigCatalog WHERE
DealerCatalog.CarIndex<>BigCatalog.CarIndex

Regards,
Shawn
--
Shawn Wilson
sh***@glassgiant.com
http://www.glassgiant.com

I have a spam filter. Please include "PHP" in the
subject line to ensure I'll get your message.
Jul 17 '05 #2
On 2004-01-13, kaptain kernel <no****@nospam.gov> wrote:
How does one retrieve the rows in a select statement that DONT match the
select.

select CarIndex FROM DealerCatalog, BigCatalog WHERE
DealerCatalog.CarIndex=BigCatalog.CarIndex

finds all the cars in the dealer catalog that are in the bigger distributor
catalog.

How do I do the opposite in a single sql statement i.e. all the dealer cars
that AREN'T in the big distributor catalog?

Is there a negative Select?


Lookup the section about the WHERE clause in your database manual.

In this case it's enough to reverse the condition.
More general you might use the not in with subquery construct.

--
http://home.mysth.be/~timvw
Jul 17 '05 #3
Tim Van Wassenhove wrote:
On 2004-01-13, kaptain kernel <no****@nospam.gov> wrote:
How does one retrieve the rows in a select statement that DONT match the
select.

select CarIndex FROM DealerCatalog, BigCatalog WHERE
DealerCatalog.CarIndex=BigCatalog.CarIndex

finds all the cars in the dealer catalog that are in the bigger distributor
catalog.

How do I do the opposite in a single sql statement i.e. all the dealer cars
that AREN'T in the big distributor catalog?

Is there a negative Select?

Lookup the section about the WHERE clause in your database manual.

In this case it's enough to reverse the condition.
More general you might use the not in with subquery construct.

The suggestions mentioned above are certainly not speedy - I had to kill
a sql query when i changed the = in my original statement to <> as
suggested above. Which tells me that the suggestions are wrong.

The answer is to use LEFT JOIN - anything that doesn't join is given a
NULL value , and it's a heck of a lot speedier of large datasets (i've
got 12,000 records):

SELECT CarIndex FROM DealerCatalog LEFT JOIN BigCatalog ON
DealerCatalog.CarIndex=BigCatalog.CarIndex WHERE BigCatalog.CarIndex IS NULL

Jul 17 '05 #4
kaptain kernel wrote:
Tim Van Wassenhove wrote:
On 2004-01-13, kaptain kernel <no****@nospam.gov> wrote:
How does one retrieve the rows in a select statement that DONT
match the select.

select CarIndex FROM DealerCatalog, BigCatalog WHERE
DealerCatalog.CarIndex=BigCatalog.CarIndex

finds all the cars in the dealer catalog that are in the bigger
distributor catalog.

How do I do the opposite in a single sql statement i.e. all the
dealer cars that AREN'T in the big distributor catalog?

Is there a negative Select?

Lookup the section about the WHERE clause in your database manual.

In this case it's enough to reverse the condition.
More general you might use the not in with subquery construct.

The suggestions mentioned above are certainly not speedy - I had to
kill a sql query when i changed the = in my original statement to
<> as
suggested above. Which tells me that the suggestions are wrong.


No kidding. You asked for a cartesian product by specifying a join of two
tables with essentially no join condition...

The answer is to use LEFT JOIN - anything that doesn't join is given a
NULL value , and it's a heck of a lot speedier of large datasets (i've
got 12,000 records):

SELECT CarIndex FROM DealerCatalog LEFT JOIN BigCatalog ON
DealerCatalog.CarIndex=BigCatalog.CarIndex WHERE BigCatalog.CarIndex
IS NULL


Actually, this is definitely not the optimal way to do it, as you are doing
a join but not using any information from the second relation. This is going
to be rather slow. Instead, do:

SELECT CarIndex FROM DealerCatalog WHERE DealerCatalog.CarIndex NOT IN
(SELECT CarIndex FROM BigCatalog);

Additionally, you should make sure that there is an index on
DealerCatalog.CarIndex and also an index on BigCatalog.CarIndex.

-Ian
Jul 17 '05 #5
or

SELECT CarIndex FROM DealerCatalog WHERE NOT EXISTS
(SELECT * FROM BigCatalog WHERE DealerCatalog.CarIndex =
BigCatalog.CarIndex);

Uzytkownik "Agelmar" <if**********@comcast.net> napisal w wiadomosci
news:bu************@ID-30799.news.uni-berlin.de...
Actually, this is definitely not the optimal way to do it, as you are doing a join but not using any information from the second relation. This is going to be rather slow. Instead, do:

SELECT CarIndex FROM DealerCatalog WHERE DealerCatalog.CarIndex NOT IN
(SELECT CarIndex FROM BigCatalog);

Additionally, you should make sure that there is an index on
DealerCatalog.CarIndex and also an index on BigCatalog.CarIndex.

-Ian

Jul 17 '05 #6
Chung Leong wrote:
or

SELECT CarIndex FROM DealerCatalog WHERE NOT EXISTS
(SELECT * FROM BigCatalog WHERE DealerCatalog.CarIndex =
BigCatalog.CarIndex);


No, that is much slower. Your method will result in a sub-query on the
database for each CarIndex in DealerCatalog. My method results in the
subquery being evaluated only once, as it is not a correlated subquery. The
database retrieves a list of CarIndex tuples from the BigCatalog relation,
and it does this only once, storing this in memory. It then probes this list
for each CarIndex in DealerCatalog. With your method, it takes CarIndex
values from DealerCatalog one at a time, and for each such value, it issues
a query against BigCatalog. Not ideal.
Jul 17 '05 #7
kaptain kernel wrote:
Tim Van Wassenhove wrote:
On 2004-01-13, kaptain kernel <no****@nospam.gov> wrote:
How does one retrieve the rows in a select statement that DONT match the
select.
[snip[
How do I do the opposite in a single sql statement i.e. all the
dealer cars
that AREN'T in the big distributor catalog?

Is there a negative Select?

[snip]
The answer is to use LEFT JOIN - anything that doesn't join is given a
NULL value , and it's a heck of a lot speedier of large datasets (i've
got 12,000 records):

SELECT CarIndex FROM DealerCatalog LEFT JOIN BigCatalog ON
DealerCatalog.CarIndex=BigCatalog.CarIndex WHERE BigCatalog.CarIndex IS
NULL


If your RDBMS vendor implemented the SET operators using the
MINUS operator may prove to be much faster; e.g.

SELECT CarIndex FROM DealerCatalog
MINUS
SELECT CarIndex FROM BigCatalog
ORDER BY 1;

Jul 17 '05 #8
kaptain kernel wrote:

Tim Van Wassenhove wrote:
On 2004-01-13, kaptain kernel <no****@nospam.gov> wrote:
How does one retrieve the rows in a select statement that DONT match the
select.

select CarIndex FROM DealerCatalog, BigCatalog WHERE
DealerCatalog.CarIndex=BigCatalog.CarIndex

finds all the cars in the dealer catalog that are in the bigger distributor
catalog.

How do I do the opposite in a single sql statement i.e. all the dealer cars
that AREN'T in the big distributor catalog?

Is there a negative Select?

Lookup the section about the WHERE clause in your database manual.

In this case it's enough to reverse the condition.
More general you might use the not in with subquery construct.


The suggestions mentioned above are certainly not speedy - I had to kill
a sql query when i changed the = in my original statement to <> as
suggested above. Which tells me that the suggestions are wrong.

The answer is to use LEFT JOIN - anything that doesn't join is given a
NULL value , and it's a heck of a lot speedier of large datasets (i've
got 12,000 records):

SELECT CarIndex FROM DealerCatalog LEFT JOIN BigCatalog ON
DealerCatalog.CarIndex=BigCatalog.CarIndex WHERE BigCatalog.CarIndex IS NULL


My apologies - I didn't notice there 2 tables. I was thinking of just a select
from a single table.

Regards,
Shawn
--
Shawn Wilson
sh***@glassgiant.com
http://www.glassgiant.com

I have a spam filter. Please include "PHP" in the
subject line to ensure I'll get your message.
Jul 17 '05 #9
Depends on the database software. On MS SQLServer using EXISTS is much
faster than using IN, rather counterintuitively.

Uzytkownik "Agelmar" <if**********@comcast.net> napisal w wiadomosci
news:bu************@ID-30799.news.uni-berlin.de...
Chung Leong wrote:
or

SELECT CarIndex FROM DealerCatalog WHERE NOT EXISTS
(SELECT * FROM BigCatalog WHERE DealerCatalog.CarIndex =
BigCatalog.CarIndex);
No, that is much slower. Your method will result in a sub-query on the
database for each CarIndex in DealerCatalog. My method results in the
subquery being evaluated only once, as it is not a correlated subquery.

The database retrieves a list of CarIndex tuples from the BigCatalog relation,
and it does this only once, storing this in memory. It then probes this list for each CarIndex in DealerCatalog. With your method, it takes CarIndex
values from DealerCatalog one at a time, and for each such value, it issues a query against BigCatalog. Not ideal.

Jul 17 '05 #10
Chung Leong wrote:
Depends on the database software. On MS SQLServer using EXISTS is much
faster than using IN, rather counterintuitively.


I wouldn't be suprised. SQL Server has a very powerful, rule-based query
optimizer. MySQL's query optimizer is far less powerful (it's quite minimal
compared to Oracle, DB2, SQL Server...), and so I'm pretty sure that it will
run the IN faster than the NOT EXISTS... but I am too lazy to make a large
data set to actually test it out :-)
Jul 17 '05 #11
I didn't even know that MySQL can handle subqueries.

Uzytkownik "Agelmar" <if**********@comcast.net> napisal w wiadomosci
news:bu************@ID-30799.news.uni-berlin.de...
Chung Leong wrote:
Depends on the database software. On MS SQLServer using EXISTS is much
faster than using IN, rather counterintuitively.
I wouldn't be suprised. SQL Server has a very powerful, rule-based query
optimizer. MySQL's query optimizer is far less powerful (it's quite

minimal compared to Oracle, DB2, SQL Server...), and so I'm pretty sure that it will run the IN faster than the NOT EXISTS... but I am too lazy to make a large
data set to actually test it out :-)

Jul 17 '05 #12
Only the latest (or next versions) can...

(I can't remember if it is the current release, or
the beta for the next one).

--
Dag.

"Chung Leong" <ch***********@hotmail.com> wrote in message
news:LO********************@comcast.com...
I didn't even know that MySQL can handle subqueries.

Uzytkownik "Agelmar" <if**********@comcast.net> napisal w wiadomosci
news:bu************@ID-30799.news.uni-berlin.de...
Chung Leong wrote:
Depends on the database software. On MS SQLServer using EXISTS is much
faster than using IN, rather counterintuitively.


I wouldn't be suprised. SQL Server has a very powerful, rule-based query
optimizer. MySQL's query optimizer is far less powerful (it's quite

minimal
compared to Oracle, DB2, SQL Server...), and so I'm pretty sure that it

will
run the IN faster than the NOT EXISTS... but I am too lazy to make a large data set to actually test it out :-)


Jul 17 '05 #13

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

12 posts views Thread by Rick | last post: by
21 posts views Thread by John Fabiani | last post: by
reply views Thread by Hans Maurer | last post: by
2 posts views Thread by Richard van Denzel | last post: by
5 posts views Thread by jayson_13 | last post: by
3 posts views Thread by Hendry Taylor | last post: by
3 posts views Thread by abighill | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.