How to produce the effect of a date range inner join without actually doing one

Question

I have a T-SQL inner date range join that has done the job, but now that I am starting to learn about query optimization (as in just starting), I'm scratching my head on how to make it better. I see the non-equi join as being the issue because the optimizer
scans through the entire table.  As you will see from the DDL code pasted below, there are no possible equi-joins. The enrollment history table has about 6000 rows so far, whereas the calendar table has only 10 so far, but is subject to change, which
is why I have it as a table join.
Another way to describe this is in the necessary outcome, which you see in the "Is_FAY" column in the Select statement. For each row in the Enrollment History table, I use the Case statement to determine whether the pair of Entry and Exit dates
are within the Calendar date ranges (and if so, which row the match is found). There are no nulls in either table by design.
At first, I thought of adding a non-clustered index, but the credible resources and blogs are mixed. Some sources say to use them, others say not to use them, and the remainder are on the fence. That and the
fact that I drop and recreate the table every 24 hours (there are many updates to the Black Box) makes me very leery about having indices other than the primary key.
I have pasted DDL language below with sample data.  Change the "Use Learning_Curve" statement to whatever database you want to use -- the rest will run as written.
Now that I've given you some background and what I hope to accomplish, I hope that someone has encountered this issue before and can suggest an avenue of further inquiry, because I am out of usable research sources and ideas. 
Thank you
USE Learning_Curve;
GO
IF OBJECT_ID('dbo.Enrollment_History', 'U') IS NOT NULL
DROP TABLE dbo.Enrollment_History;
CREATE TABLE dbo.Enrollment_History
(ID INT NOT NULL identity(1, 1) PRIMARY KEY,
Campus_ID INT NOT NULL,
Student_ID INT NOT NULL,
Entry_Date DATE NOT NULL,
Exit_Date DATE NOT NULL);
INSERT INTO dbo.Enrollment_History
VALUES (1, 103934, '2014-08-11', '2015-01-10'),
(1, 102912, '2014-09-10', '2015-05-10'),
(1, 199234, '2014-08-07', '2015-05-01');
IF OBJECT_ID('dbo.Calendar_FAY_Dates', 'U') IS NOT NULL
DROP TABLE dbo.Calendar_FAY_Dates;
CREATE TABLE dbo.Calendar_FAY_Dates
(ID INT NOT NULL identity(1, 1) PRIMARY KEY,
FY VARCHAR(4) NOT NULL,
Start_B DATE NOT NULL,
Start_E DATE NOT NULL,
End_B DATE NOT NULL,
End_E DATE NOT NULL);
INSERT INTO dbo.Calendar_FAY_Dates
VALUES ('FY14', '2013-08-05', '2013-08-29', '2014-04-30', '2014-05-15'),
('FY15', '2014-08-07', '2014-08-28', '2015-04-30', '2015-05-15');
SELECT eh.ID,
eh.Campus_ID,
eh.Student_ID,
eh.Entry_Date,
eh.Exit_Date,
cfd.FY,
case
when eh.Entry_Date >= cfd.Start_B
and eh.Entry_Date <= cfd.Start_E
and eh.Exit_Date >=cfd.End_B
and eh.Exit_Date <= cfd.End_E
then 1 else 0 end as Is_FAY
FROM dbo.Enrollment_History eh
inner join dbo.Calendar_FAY_Dates cfd
on eh.Entry_Date >= cfd.Start_B
and eh.Exit_Date <= cfd.End_E

Answer 1

This definitely a case where an indexes on the two tables will speed things up significantly. 
It's also one of those strange cases where you can't really rely on the numbers you see in the execution plan. To really get an idea the impact to need to actually time the query...
For example. Running your final query with out any additional indexes took ~4,000 microseconds...
Adding the following index, dropped that time down to ~3,000 microseconds...
CREATE NONCLUSTERED INDEX ix_Enrollment_History_EntryDates ON dbo.Enrollment_History (
Entry_Date,
Exit_Date)
INCLUDE (
ID,
Campus_ID,
Student_ID)
WITH (DATA_COMPRESSION = PAGE)
Adding the following index (and keeping the 1st) dropped it again, down to ~2,000 microseconds
CREATE NONCLUSTERED INDEX ix_CalendarFAYDates_Detes ON dbo.Calendar_FAY_Dates (
Start_B,
End_E)
INCLUDE (
Start_E,
End_B,
ID,
FY)
WITH (DATA_COMPRESSION = PAGE)
Keep in mind that 5 rows of data doesn't even begin to provide an accurate representation of read execution times against actual production data (the smallest changes in background processes on my computer caused the time to vary pretty drastically between
executions).
Anyway, the following is a quick & dirty way to test execution times when you're query tuning or checking the impact of different indexes on a query.
DECLARE @b DATETIME2(7) = SYSDATETIME()
SELECT eh.ID,
eh.Campus_ID,
eh.Student_ID,
eh.Entry_Date,
eh.Exit_Date,
cfd.FY,
case
when eh.Entry_Date >= cfd.Start_B
and eh.Entry_Date <= cfd.Start_E
and eh.Exit_Date >=cfd.End_B
and eh.Exit_Date <= cfd.End_E
then 1 else 0 end as Is_FAY
FROM dbo.Enrollment_History eh
inner join dbo.Calendar_FAY_Dates cfd
on eh.Entry_Date >= cfd.Start_B
and eh.Exit_Date <= cfd.End_E
SELECT DATEDIFF(mcs, @b, SYSDATETIME())
HTH,
Jason
Jason Long