Comments on: SELECT and WHERE, but no FROM clause

By: Rob Farley

Rob Farley — Thu, 16 Jul 2015 03:15:37 +0000

Try:
SELECT *
FROM (
SELECT … FROM ….
UNION
SELECT … FROM ….
) AS u
WHERE …

By: RK

RK — Wed, 15 Jul 2015 22:09:27 +0000

I am combining two tables using a UNION operator. However, I would like to choose a subset of the resulting data with a where clause. I am getting an error when I use the where clause. Is there a simple solution to this problem.

By: Rob Farley

Rob Farley — Mon, 18 Apr 2011 06:33:48 +0000

Hi Paul,
I’m not convinced it is nicer.
It’s almost identical (but has an extra operator) to the version that uses VALUES. But when you compare it to the UNION ALL version, you see a few differences.
The difference that I see as significant is that the Filter for OrigShip appears before the concatenation, but when using UNPIVOT, it puts the Filter at the end (with 125860 being checked, 94404 going through), instead of a start-up filter that would be being used only 31465 times.
But my main point is regarding the flexibility. UNPIVOT feels so inflexible, whereas APPLY can be used in far more ways.
Thanks for your comment though – I always appreciate your feedback on these things.
Rob

By: Paul White

Paul White — Mon, 18 Apr 2011 05:04:42 +0000

Hey Rob,
I’m a fan of UNPIVOT myself. The following produces a nicer query plan (to my mind anyway) than the APPLY syntax:
WITH Src
AS (
SELECT SalesOrderID,
OrderDate,
ShipDate,
DueDate,
OrigShip =
CASE
WHEN ShipDate > DATEADD(DAY, 7, OrderDate)
THEN DATEADD(DAY, 7, OrderDate)
END
FROM Sales.SalesOrderHeader
)
SELECT D.SalesOrderID,
D.DateType,
D.[Date]
FROM Src
UNPIVOT (
[Date] FOR DateType IN (OrderDate, ShipDate, DueDate, OrigShip)
) AS D
;
What do you think?
Paul

By: Rob Farley

Rob Farley — Mon, 18 Apr 2011 00:40:00 +0000

Hi Joe,
Yes, I’m most definitely restricting myself to T-SQL here. Oracle was my first RDBMS, and I was fine with following its rules regarding SET and DUAL. Having moved to the T-SQL world, I discovered that ANSI was broken in other ways. Some I liked, some I didn’t.
As much as I would like T-SQL to be as ANSI-like as possible, I also try to welcome the differences.
Rob

By: Joe Celko

Joe Celko — Sun, 17 Apr 2011 18:16:19 +0000

T-SQL overloads the SELECT keyuword; ANSI does not. The <select sttement> does require a <FROM clause>; read your ANSI/ISO Standards. I am doing this off the top of my head. The <assign statement> in Standard SQL is SET <target row consructor> = <expression row constructor>; The <assign statement> in T-SQL dialect is [SET | SELECT] <scalar assignment> {, <scalar assignment>}; <scalar assignment> ::= <variable> = <expression> Whwre SET can take only one scalar assignment. And, as you pointed out, T-SQL is a nightmare of bad proprietary syntax.

By: Matt Velic

Matt Velic — Tue, 12 Apr 2011 17:34:52 +0000

Thanks for participating, Rob! I knew that FROM was optional, but I hadn’t thought of using APPLY instead of UNPIVOT. In my defense, I’ve never had to UNPIVOT anything, but I’m happy to have found my new method for when I do!

By: Brad Schulz

Brad Schulz — Tue, 12 Apr 2011 06:31:48 +0000

Excellent argument for the UNION ALL approach! I like it!
(And thanks for the mention).
–Brad