I have two tables both of which have columns StartDate and EndDate.
I'm trying to return a single resultset that contains all date ranges from one table (TableA), and all complement date ranges from the other one (TableB).
CREATE TABLE [dbo].[TableA](
[ID] [int] NOT NULL,
[StartDate] [datetime] NOT NULL,
[EndDate] [datetime] NOT NULL
)
CREATE TABLE [dbo].[TableB](
[ID] [int] NOT NULL,
[StartDate] [datetime] NOT NULL,
[EndDate] [datetime] NOT NULL
)
INSERT INTO TableA (ID, StartDate, EndDate) VALUES(1, '4/1/2009', '8/1/2009')
INSERT INTO TableA (ID, StartDate, EndDate) VALUES(1, '10/1/2009', '12/1/2009')
INSERT INTO TableB (ID, StartDate, EndDate) VALUES(1, '1/1/2009', '2/1/2010')
INSERT INTO TableA (ID, StartDate, EndDate) VALUES(2, '4/1/2009', '8/1/2009')
INSERT INTO TableB (ID, StartDate, EndDate) VALUES(2, '1/1/2009', '5/1/2009')
INSERT INTO TableB (ID, StartDate, EndDate) VALUES(2, '7/1/2009', '12/1/2009')
The expected resultset from the three datasets should be:
(ID = 1)
1/1/2009 - 4/1/2009 (from TableB)
4/1/2009 - 8/1/2009 (from TableA)
8/1/2009 - 10/1/2009 (from TableB)
10/1/2009 - 12/1/2009 (from TableA)
12/1/2009 - 2/1/2010 (from TableB)
(ID = 2)
1/1/2009 - 4/1/2009 (from TableB)
4/1/2009 - 8/1/2009 (from TableA)
8/1/2009 - 12/1/2009 (from TableB)
The date ranges are not guaranteed to be continuous, and I can't make any assumptions on how they're overlapping between tables...within each table they can be assumed to not overlap.
I'm having problems wrapping my head around how to split the single date ranges in TableB into multiple pieces to find all the complement "regions" within it in SQL.
Anyone have any suggestions?
If you create this as a view, I think it does what you want. It uses CTEs, which should be supported by SQL Server 2005, but not earlier.
Full output (ordered by Id, StartDate for readability):
It was pretty complicated for me to implement this, so I'm wondering if anyone can see a simpler way. I might be missing some trick that makes this much simpler. If so, please let me know! Also, you will almost certainly need some indexes on your tables to get this to perform well if you have a lot of rows. Some other optimizations may be possible - I haven't tried for the fastest possible performance, but just to get the correct result.