|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Tuesday, April 23, 2013 6:01 PM
Points: 9,
Visits: 319
|
|
|
|
|
|
Valued Member
      
Group: General Forum Members
Last Login: Monday, December 10, 2012 4:42 AM
Points: 65,
Visits: 11
|
|
| Here i didn't get the use of this query. Please can u give a real time example on this...
|
|
|
|
|
SSC Veteran
      
Group: General Forum Members
Last Login: Sunday, July 03, 2011 7:09 AM
Points: 258,
Visits: 494
|
|
If I read this correctly, you just implemented the LAG(...) Over(...) analytic function.
However, I'm interested... if you do this on a large dataset, what does the execution plan look like?
Random Technical Stuff
|
|
|
|
|
SSC Eights!
      
Group: General Forum Members
Last Login: Yesterday @ 3:38 AM
Points: 803,
Visits: 2,123
|
|
I think this would be of use in planning/supply systems where you want to know about future availablity of resources.
However it is slightly misleading in that I would have thought PersonId should have 3 rows, and not two, as they will be resourced up until the end of December 2010.
_________________________________________________________________________ SSC Guide to Posting and Best Practices
|
|
|
|
|
Mr or Mrs. 500
      
Group: General Forum Members
Last Login: Wednesday, May 15, 2013 12:43 AM
Points: 582,
Visits: 1,601
|
|
| Shouldn't you have a LEFT JOIN rather than an INNER JOIN?
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Yesterday @ 9:15 AM
Points: 5,603,
Visits: 10,959
|
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Tuesday, May 07, 2013 3:28 AM
Points: 115,
Visits: 719
|
|
I don't think you're going to find that in BOL, Chris; unless I am mistaken LEAD and LAG are not supported by SQL Server. Oracle uses them to access values in a previous or next row - see this article. Let's hope Microsoft adds them to a future version of SQL Server.
Kevin, I too am curious about the performance of your method on large data sets. Doing a self-join with a WHERE a < b condition generally leads to very slow queries as the table gets large - a triangular join has Order N2 performance. But using a partition ought to be much more efficient.
|
|
|
|
|
Hall of Fame
       
Group: General Forum Members
Last Login: Today @ 12:32 AM
Points: 3,574,
Visits: 5,112
|
|
We SOOOOOOO need full Windowing Function support in SQL Server. And yes, performance on this type of query will currently be exceptionally poor and approaching non-functional on increasingly large datasets.
Best,
Kevin G. Boles SQL Server Consultant SQL MVP 2007-2012 TheSQLGuru at GMail
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Yesterday @ 9:15 AM
Points: 5,603,
Visits: 10,959
|
|
TheSQLGuru (10/11/2010) We SOOOOOOO need full Windowing Function support in SQL Server. And yes, performance on this type of query will currently be exceptionally poor and approaching non-functional on increasingly large datasets.
Not so. Always check.
----------------------------------------------------------- -- Create a working table to play with. -----------------------------------------------------------
DROP TABLE #Numbers SELECT TOP 1000000 n = ROW_NUMBER() OVER (ORDER BY a.name), CalcValue = CAST(NULL AS BIGINT) INTO #Numbers FROM master.dbo.syscolumns a, master.dbo.syscolumns b CREATE UNIQUE CLUSTERED INDEX CIn ON #Numbers ([n] ASC) ----------------------------------------------------------- -- run a test against the table ----------------------------------------------------------- SET STATISTICS IO ON SET STATISTICS TIME ON
SELECT a.*, B.n AS Nextrow INTO #junk FROM #Numbers a INNER JOIN #Numbers b ON b.n = a.n + 1
-- (999999 row(s) affected) / CPU time = 3516 ms, elapsed time = 3538 ms. -- Table 'Worktable'. Scan count 2, logical reads 6224, physical reads 0, read-ahead reads 0, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SET STATISTICS IO Off SET STATISTICS TIME Off
DROP TABLE #junk
----------------------------------------------------------- -- run a functionally similar test against a CTE of the table with ROW_NUMBER() generating "row IDs" ----------------------------------------------------------- SET STATISTICS IO ON SET STATISTICS TIME ON
;WITH CTE AS (SELECT NewRowNumber = ROW_NUMBER() OVER (ORDER BY n DESC) FROM #Numbers) SELECT a.*, B.NewRowNumber AS Nextrow INTO #junk FROM CTE a INNER JOIN CTE b ON b.NewRowNumber = a.NewRowNumber + 1
-- (999999 row(s) affected) / CPU time = 7781 ms, elapsed time = 7808 ms. -- Table 'Worktable'. Scan count 2, logical reads 6224, physical reads 0, read-ahead reads 5, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.
SET STATISTICS IO Off SET STATISTICS TIME Off
“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
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Friday, February 01, 2013 2:43 AM
Points: 1,
Visits: 30
|
|
Real use of this query: Hospitals in the UK are penalised if patients have to wait too long for their operations. If the patient cancels an appointment the timer is reset on the waiting time. if the hospital cancels, the waiting time is not reset. (It's actually a lot more complex, but that's the basic principle)
Last year I was asked to sort out some ETL stored procedures used in waiting time calculations that were taking over 20 hours to run. These procs were using cursors. I replaced the stored procs with ones using very similar code to that shown here. The run time dropped from 20 hours + to less than 10 minutes.
Hope that's real enough 
Glyn
|
|
|
|