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»»

How to Compare Rows within Partitioned Sets to Find Overlapping Dates Expand / Collapse
Author
Message
Posted Saturday, October 9, 2010 1:19 PM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Saturday, May 3, 2014 11:52 PM
Points: 9, Visits: 327
Comments posted to this topic are about the item How to Compare Rows within Partitioned Sets to Find Overlapping Dates
Post #1001748
Posted Monday, October 11, 2010 12:38 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Wednesday, August 14, 2013 9:23 AM
Points: 68, Visits: 18
Here i didn't get the use of this query. Please can u give a real time example on this...
Post #1001945
Posted Monday, October 11, 2010 3:17 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Sunday, July 3, 2011 7:09 AM
Points: 233, 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
Post #1002000
Posted Monday, October 11, 2010 4:47 AM
SSC Eights!

SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!SSC Eights!

Group: General Forum Members
Last Login: Friday, October 3, 2014 9:25 AM
Points: 895, Visits: 2,432
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
Post #1002049
Posted Monday, October 11, 2010 5:12 AM
SSChasing Mays

SSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing MaysSSChasing Mays

Group: General Forum Members
Last Login: Friday, October 17, 2014 12:54 AM
Points: 648, Visits: 1,876
Shouldn't you have a LEFT JOIN rather than an INNER JOIN?
Post #1002063
Posted Monday, October 11, 2010 5:54 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 9:54 AM
Points: 6,813, Visits: 14,028
ta.bu.shi.da.yu (10/11/2010)
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?


Got a BOL clicky-link for this, by any chance?


“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 #1002093
Posted Monday, October 11, 2010 6:45 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, September 30, 2014 3:20 PM
Points: 115, Visits: 747
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.
Post #1002119
Posted Monday, October 11, 2010 7:56 AM


SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Yesterday @ 9:57 AM
Points: 4,406, Visits: 6,270
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
Post #1002183
Posted Monday, October 11, 2010 8:15 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: 2 days ago @ 9:54 AM
Points: 6,813, Visits: 14,028
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
Post #1002201
Posted Monday, October 11, 2010 9:35 AM
Forum Newbie

Forum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum NewbieForum Newbie

Group: General Forum Members
Last Login: Monday, September 1, 2014 4:21 AM
Points: 3, Visits: 48
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

Post #1002269
« Prev Topic | Next Topic »

Add to briefcase 12»»

Permissions Expand / Collapse