Create Dates table as stored procedure

Question

I want to modify this statement to use todays date as the start date and add 50 years to insert into table instead of entering a date range and execute it as a stored procedure. Can someone help me to modify this? Thanks
/**Drop Tables*/
DROP TABLE [dbo].[DimDate]
GO
/** Create Date Dimension Table **/
/* Create First numbers table for key generation */
CREATE TABLE Numbers_Small (Number INT);
INSERT INTO Numbers_Small
VALUES (0)
,(1)
,(2)
,(3)
,(4)
,(5)
,(6)
,(7)
,(8)
,(9);
GO
/* Create Second numbers table for key generation */
CREATE TABLE Numbers_Big (Number_Big BIGINT);
INSERT INTO Numbers_Big (Number_Big)
SELECT (tenthousands.number * 10000 + thousands.number * 1000 + hundreds.number * 100 + tens.number * 10 + ones.number) AS number_big
FROM numbers_small tenthousands
,numbers_small thousands
,numbers_small hundreds
,numbers_small tens
,numbers_small ones;
GO
/* Create Date Dimension Table */
CREATE TABLE [dbo].[DimDate] (
[DateKey] [int] NOT NULL
,[Date] [datetime] NOT NULL
,[Day] [char](10) NULL
,[DayOfWeek] [smallint] NULL
,[DayOfMonth] [smallint] NULL
,[DayOfYear] [smallint] NULL
,[PreviousDay] [datetime] NULL
,[NextDay] [datetime] NULL
,[WeekOfYear] [smallint] NULL
,[Month] [char](10) NULL
,[MonthOfYear] [smallint] NULL
,[QuarterOfYear] [smallint] NULL
,[Year] [int] NULL
GO
/* Create Date Key and Date Fields */
INSERT INTO [DimDate] (
DateKey
,DATE
SELECT number_big
,DATEADD(day, number_big, '1900-01-01') AS DATE
FROM numbers_big
WHERE DATEADD(day, number_big, '1900-01-01') BETWEEN '1900-01-01'
AND '2050-12-31'
ORDER BY number_big;
GO
/* Update all other fields with appropriate data. */
UPDATE [DimDate]
SET Day = DATENAME(DW, DATE)
,DayOfWeek = DATEPART(WEEKDAY, DATE)
,DayOfMonth = DAY(DATE)
,DayOfYear = DATEPART(DY, DATE)
,PreviousDay = DATEADD(DAY, - 1, DATE)
,NextDay = DATEADD(DAY, 1, DATE)
,WeekOfYear = DATEPART(WK, DATE)
,Month = DATENAME(MONTH, DATE)
,MonthOfYear = MONTH(DATE)
,QuarterOfYear = DATEPART(Q, DATE)
,Year = YEAR(DATE);
GO
/* Drop Temp Tables */
DROP TABLE Numbers_Small;
DROP TABLE Numbers_Big;

Answer 1

SQL is a database language, so why do you want to re-compute constant data over and over, hundreds of times a day for years? UGH! 
There are 365.2422 days per year, so a century of calender data is only 36,525 rows! Maybe 40 bytes per row? About 1.5 Kbytes  total? This will fit into main storage
What you did post was wrong. DATE is a reserved word in SQL and it is  unit of temporal measurement. You also seem to confuse columns and fields. In SQL a field is a sub-unit of a temporal measurement (YEARS, MONTH, DAY, HOUR, MINUTE, SECOND). Please
learn the ISO-11179 rules for data element names.
You crammed too much in the table. The new DATE data type is only 3 bytes! Your other columns are mostly redundant and have attribute splitting problems.  Try this:
CREATE TABLE Calendar 
(cal_date DATE NOT NULL PRIMARY KEY,
 julian_date INTEGER NOT NULL, 
 julian_business_day INTEGER NOT NULL, 
 ordinal_date CHAR(8) NOT NULL
   CHECK (ordinal_date 
       LIKE '[12][0-9][0-9][0-9]-[0-9][0-9][0-9]') NOT NULL,
 week_date CHAR(9) NOT NULL
    CHECK (week_date LIKE '[12][0-9][0-9][0-9]W[0-5][0-9]-[0-7])
The julianized date is a sequential number over the whole calendar. It makes temporal math easier. 
ISO-8601 week_date is the week-within-year. This format is 'yyyyWww-d' where yyyy is the year, W is a separator token, ww is (01-53) week number and d is (1-7) day of the week. 
There are several websites with calendars you can cut & paste, but you can start your search with: http://www.calendar-365.com/week-number.html 
The Julian business day is a good trick. Number the days from whenever your calendar starts and repeat a number for a weekend or company holiday. 
CREATE TABLE Calendar
(cal_date DATE NOT NULL PRIMARY KEY, 
 julian_business_nbr INTEGER NOT NULL, 
INSERT INTO Calendar 
VALUES ('2007-04-05', 42), 
 ('2007-04-06', 43), -- good Friday 
 ('2007-04-07', 43), 
 ('2007-04-08', 43), -- Easter Sunday 
 ('2007-04-09', 44), 
 ('2007-04-10', 45); --Tuesday
To compute the business days from Thursday of this week to next
 Tuesdays:
SELECT (C2.julian_business_nbr - C1.julian_business_nbr)
  FROM Calendar AS C1, Calendar AS C2
 WHERE C1.cal_date = '2007-04-05',
   AND C2.cal_date = '2007-04-10'; 
Why store things like the month name in the table? This is a display field, not a schema column value. It is language dependent! It is only part of a scalar value, too; why not normalize? 
But if you need them, then use computed columns that are not materialized until needed. Also, use the SUBSTRING() for things that are not numeric. Why use SMALLINT for the day of the week?  Are you going to divide Thursday by 42? It is a name, not a numeric. 
You saw the tricks with a Series table wanted to use them, but do not  be the boy with a new hammer who thinks everything is a nail. I find that a spreadsheet is the best way to create such a calendar table because they have so many temporal options and
functions. 
Also, putting the comma at the start of  a line is an old punchcard trick that we do not use any more. Back in the 1960's, it let us re-arrange the deck and re-use the cards. All it cost us was readable code –- your eyes expect to see a comma after a string,
so this makes a twitch as you read. 
--CELKO-- Books in Celko Series for Morgan-Kaufmann Publishing: Analytics and OLAP in SQL / Data and Databases: Concepts in Practice Data / Measurements and Standards in SQL SQL for Smarties / SQL Programming Style / SQL Puzzles and Answers / Thinking
in Sets / Trees and Hierarchies in SQL