Caution with EXCEPT

Question

Caution with EXCEPT

zintp

SSChasing Mays

Points: 614
More actions
January 16, 2010 at 6:28 pm

#229165

Comments posted to this topic are about the item Caution with EXCEPT

Viewing 15 posts - 1 through 15 (of 29 total)

You must be logged in to reply to this topic. Login to reply

mohd.nizamuddin Ten Centuries Points: 1328 More actions · Answer 1

Very nice and informative article...

This is what we do in real life as well (Use of SELECT *). Even though we hear from everybody that to avoid SELECT * always.

So, if we make practice of writing SELECT col1, col2, col3,.... then we would not get that problem.

Enjoy.

Tobar SSCarpal Tunnel Points: 4876 More actions · Answer 2

Another issue with select * is that if you have identity keys and the tables are independently generated (as in deve and staging) and an identical data entry has separate "identities" on the different boxes select * will always return all the rows.

Instead of the Union I usually just

select * from A

except

select * from B

except

select * from A

then you can it is easier to know where the "differences" originate.

<><
Livin' down on the cube farm. Left, left, then a right.

Tobar SSCarpal Tunnel Points: 4876 More actions · Answer 3

mohd.nizamuddin (1/17/2010)
Very nice and informative article...
This is what we do in real life as well (Use of SELECT *). Even though we hear from everybody that to avoid SELECT * always.
So, if we make practice of writing SELECT col1, col2, col3,.... then we would not get that problem.
Enjoy.

Sorry for 2 responses. More thoughts occurred as the coffee kicked in.

I "always" 😉 start to worry when someone used the phrase "always", there are always reasons why always is never appropriate. (Same goes with "never"). Sometimes it is just the thing to do.

When needing to "select col1, col2, etc." I use the Management Studio tactic of "Script table as->Select into->new query window" and then just hack out any columns I do not want. It "Always" works for me.

<><
Livin' down on the cube farm. Left, left, then a right.

Stephen Hirsch SSCommitted Points: 1822 More actions · Answer 4

Here's a better way:

SELECT 'IN A NOT B' location, a, b, c, d, ...

FROM tablea

EXCEPT

SELECT 'IN A NOT B' location, a, b, c, d, ...

FROM tableb

UNION ALL

SELECT 'IN B NOT A' location, a, b, c, d, ...

FROM tableb

EXCEPT

SELECT 'IN B NOT A' location, a, b, c, d, ...

FROM tablea

No parentheses this way.

ChrisM@Work SSC Guru Points: 186127 More actions · Answer 5

Stephen Hirsch (1/18/2010)
Here's a better way:
SELECT 'IN A NOT B' location, a, b, c, d, ...
FROM tablea
EXCEPT
SELECT 'IN A NOT B' location, a, b, c, d, ...
FROM tableb
UNION ALL
SELECT 'IN B NOT A' location, a, b, c, d, ...
FROM tableb
EXCEPT
SELECT 'IN B NOT A' location, a, b, c, d, ...
FROM tablea
No parentheses this way.

Wait a minute! If ever there was a case for parentheses, it's right here - what was the intent of the programmer? Parentheses make the intent self-documenting:

SELECT 'IN A NOT B' location, a, b, c, d, ...

FROM tablea

EXCEPT

(SELECT 'IN A NOT B' location, a, b, c, d, ...

FROM tableb

UNION ALL

SELECT 'IN B NOT A' location, a, b, c, d, ...

FROM tableb

EXCEPT

SELECT 'IN B NOT A' location, a, b, c, d, ...

FROM tablea)

Cheers

ChrisM

^{“Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw}

For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden

Tobar SSCarpal Tunnel Points: 4876 More actions · Answer 6

The programmer "intended" it to work the way the programmer thought they were programming it to work. 😀 [this said in the universal sense]

<><
Livin' down on the cube farm. Left, left, then a right.

ChrisM@Work SSC Guru Points: 186127 More actions · Answer 7

Tobar (1/18/2010)
The programmer "intended" it to work the way the programmer thought they were programming it to work. 😀 [this said in the universal sense]

LOL you used to work there too!

^{“Write the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw}

For fast, accurate and documented assistance in answering your questions, please read this article.
Understanding and using APPLY, (I) and (II) Paul White
Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden

bugmenot-573553 SSC Veteran Points: 231 More actions · Answer 8

We have seen poor performance with EXCEPT on large data sets.

Sam Jumper Valued Member Points: 55 More actions · Answer 9

Thanks for the article, I've never used EXCEPT because I didn't realize it existed.

On the point of poor performance with large datasets, how can we expect anything else? Probably too many columns to put in a covering index. SQL has to compare every column to every column, it's going to either table scan or bookmark lookup every row. Give your SQL Server a break! I suppose when I think about it, you could include a WHERE statement to break your large datasets in to smaller ones if appropriate to what you are looking for.

jdurandt SSChasing Mays Points: 628 More actions · Answer 10

That's interesting

I benchmarked EXCEPT vs WHERE NOT IN (SELECT .....), and for my dataset, server, DB version etc. the performance results were equivalent, or biased towards EXCEPT.

Can you give more details about your scenario?

jdurandt SSChasing Mays Points: 628 More actions · Answer 11

I find that an easier way to get the list of columns is to drag them from the object explorer in SSMS. If you expand the table object's columns list, you can then drag the "Columns" parent entry into a query window, to get the comma seperated list of columns.

This works for some other items too.

Mike DiRenzo SSCrazy Points: 2013 More actions · Answer 12

Bravo! What a great catch. You have my 5 star vote.

-Mike

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 13

jdurandt (1/18/2010)
That's interesting
I benchmarked EXCEPT vs WHERE NOT IN (SELECT .....), and for my dataset, server, DB version etc. the performance results were equivalent, or biased towards EXCEPT.
Can you give more details about your scenario?

Can you post your benchmark code, please?

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Jeff Moden SSC Guru Points: 1004406 More actions · Answer 14

Nicely done, Stephen. Well written and straight to the point.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)