Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase ««12

Compare the text in a string (Re-post) Expand / Collapse
Author
Message
Posted Wednesday, July 4, 2012 4:46 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 3:25 AM
Points: 3,648, Visits: 5,328
I just made the most awesome discovery while using cascading CROSS APPLYs so I thought I'd post it here.

Did you know that inside the CROSS APPLY if you refer to a name that's ambiguous in the left table, that the CROSS APPLY assumes that it is from the inner table? To use the column from the left table (if ambiguous) you must then qualify it with the table alias.

That is awesome cool and very handy to make the code concise!

All right, everybody already knew that so I'll shut up now. Just had to tell somebody.

Might be something worth mentioning in your article though Chris.



My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

My thought question: Have you ever been told that your query runs too fast?

My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.


Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
Post #1324910
Posted Wednesday, July 4, 2012 5:22 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Friday, September 12, 2014 9:43 AM
Points: 7,284, Visits: 13,824
dwain.c (7/4/2012)
I just made the most awesome discovery while using cascading CROSS APPLYs so I thought I'd post it here.

Did you know that inside the CROSS APPLY if you refer to a name that's ambiguous in the left table, that the CROSS APPLY assumes that it is from the inner table? To use the column from the left table (if ambiguous) you must then qualify it with the table alias.

That is awesome cool and very handy to make the code concise!

All right, everybody already knew that so I'll shut up now. Just had to tell somebody.

Might be something worth mentioning in your article though Chris.


Have you got an example, Dwain?


“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
Exploring Recursive CTEs by Example Dwain Camps
Post #1324944
Posted Wednesday, July 4, 2012 9:10 AM
Old Hand

Old HandOld HandOld HandOld HandOld HandOld HandOld HandOld Hand

Group: General Forum Members
Last Login: Thursday, October 31, 2013 3:44 AM
Points: 314, Visits: 4,128
ChrisM@Work (7/4/2012)
dwain.c (7/4/2012)
I just made the most awesome discovery while using cascading CROSS APPLYs so I thought I'd post it here.

Did you know that inside the CROSS APPLY if you refer to a name that's ambiguous in the left table, that the CROSS APPLY assumes that it is from the inner table? To use the column from the left table (if ambiguous) you must then qualify it with the table alias.

That is awesome cool and very handy to make the code concise!

All right, everybody already knew that so I'll shut up now. Just had to tell somebody.

Might be something worth mentioning in your article though Chris.


Have you got an example, Dwain?


I think Dwain might be referrring to the issue raised in these links:

http://www.sqlservercentral.com/Forums/Topic890645-338-1.aspx#bm891174
http://www.sqlservercentral.com/blogs/dave_ballantynes_blog/2010/03/26/cross-apply-ambiguity/
Post #1325057
Posted Wednesday, July 4, 2012 10:04 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: General Forum Members
Last Login: Today @ 4:00 PM
Points: 37,105, Visits: 31,662
ChrisM@Work (6/27/2012)
This technique isn't exactly new though. I can remember the first time I posted a solution using it, possibly as long as a couple of years ago. However, if you feel it's worthwhile (a few recent posts suggests it might be), then I'll go for it.


Consider what happened with the Tally Table. It was actually a technique that some folks used on main frames way back when. Since then, it's been written about dozens if not hundreds of times and who knows how many thousands of posts there were on the subject before I wrote about it. I wrote about it because, despite the number of times it had been written about and posted, people weren't getting how it worked.

Now, consider that I hadn't even considered using the output of one CROSS APPLY in another in the same query. How many other folks may be missing that epiphany?

Start the introduction of the article with something like "Yeah... I know this is an old trick but, judging from the number of posts that could actually benefit from it, I thought I'd write about it so that even a Neophyte to SQL can understand it well enough to take advantage of the power and simplicity-of-code the technique offers."

It would make a great "Spackle" article.


--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."

(play on words) "Just because you CAN do something in T-SQL, doesn't mean you SHOULDN'T." --22 Aug 2013

Helpful Links:
How to post code problems
How to post performance problems
Post #1325085
Posted Wednesday, July 4, 2012 8:17 PM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Today @ 3:25 AM
Points: 3,648, Visits: 5,328
ChrisM@Work (7/4/2012)
dwain.c (7/4/2012)
I just made the most awesome discovery while using cascading CROSS APPLYs so I thought I'd post it here.

Did you know that inside the CROSS APPLY if you refer to a name that's ambiguous in the left table, that the CROSS APPLY assumes that it is from the inner table? To use the column from the left table (if ambiguous) you must then qualify it with the table alias.

That is awesome cool and very handy to make the code concise!

All right, everybody already knew that so I'll shut up now. Just had to tell somebody.

Might be something worth mentioning in your article though Chris.


Have you got an example, Dwain?


Indeed I do! Take a look at the code I posted here: http://www.sqlservercentral.com/Forums/Topic1318149-392-10.aspx?Update=1, specifically the code I referred to as the "mother of all cascaded CROSS APPLYs" (last SQL script).

A little explanation is in order I suppose. Stealing a chunk of that code (that won't run on its own):

FROM BaseDistricts base
-- Try: [6,55] Fail (no rows returned)
-- Try: [8,25] Success (at least one row returned)
CROSS APPLY (
SELECT d13=d1, d14=d2, dall, [population]
FROM dbo.NewDistricts
WHERE n = 2 AND d1 = 8 AND d2 = 25 AND
d1 NOT IN (base.d1,base.d2,base.d3,d4,d5,d6,d7,d8,d9,d10,d11,d12) AND
d2 NOT IN (base.d1,base.d2,base.d3,d4,d5,d6,d7,d8,d9,d10,d11,d12)) a
-- Try: [8,66] Fail
-- Try: [25,55] Fail
-- Try: [36,40] Success!
CROSS APPLY (
SELECT d15=d1, d16=d2, dall, [population]
FROM dbo.NewDistricts
WHERE n = 2 AND d1 = 36 AND d2 = 40 AND
d1 NOT IN (base.d1,base.d2,base.d3,d4,d5,d6,d7,d8,d9,d10,d11,d12,d13,d14) AND
d2 NOT IN (base.d1,base.d2,base.d3,d4,d5,d6,d7,d8,d9,d10,d11,d12,d13,d14)) b


1. BaseDistricts is my base table and it contains the columns d1, d2, ... d12.
2. Derived table a references all 12 of these fields, however only d1 and d2 need to be qualified as base. I also qualified d3 for purposes down the line.
3. Derived table a creates a new d1 and d2 which can be referred to locally and are known as such without qualification. You only need to qualify d1 when you want to refer to the version created by base.
4. Derived table b now references d13 and d14, which were created in derived table a also without qualification. Once again, non-qualified references to d1 and d2 refer to the d1 and d2 that come out of the NewDistricts table.

Perhaps this should be known as a cascading, correlated CROSS APPLY!

Hope that helps!



My mantra: No loops! No CURSORs! No RBAR! Hoo-uh!

My thought question: Have you ever been told that your query runs too fast?

My advice:
INDEXing a poor-performing query is like putting sugar on cat food. Yeah, it probably tastes better but are you sure you want to eat it?
The path of least resistance can be a slippery slope. Take care that fixing your fixes of fixes doesn't snowball and end up costing you more than fixing the root cause would have in the first place.


Need to UNPIVOT? Why not CROSS APPLY VALUES instead?
Since random numbers are too important to be left to chance, let's generate some!
Learn to understand recursive CTEs by example.
Splitting strings based on patterns can be fast!
Post #1325153
« Prev Topic | Next Topic »

Add to briefcase ««12

Permissions Expand / Collapse