<a href="http://g.adspeed.net/ad.php?do=clk&zid=15220&wd=468&ht=60&pair=as" target="_blank"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15220&wd=468&ht=60&pair=as" alt="i" width="468" height="60"/></a>
Log in
::
Register
::
Not logged in
Home
Tags
Articles
Editorials
Stairways
Forums
Scripts
Videos
Blogs
QotD
Books
Ask SSC
SQL Jobs
Training
Authors
About us
Contact us
Newsletters
Write for us
<a href="http://g.adspeed.net/ad.php?do=clk&zid=15491&wd=120&ht=300&pair=as" target="_top"><img style="border:0px;" src="http://g.adspeed.net/ad.php?do=img&zid=15491&wd=120&ht=300&pair=as" alt="i" width="120" height="300"/></a>
Recent Posts
Recent Posts
Popular Topics
Popular Topics
Home
Search
Members
Calendar
Who's On
Home
»
SQL Server 2008
»
T-SQL (SS2K8)
»
Fiscal Dates
Fiscal Dates
Rate Topic
Display Mode
Topic Options
Author
Message
rka
rka
Posted Sunday, September 02, 2012 8:54 PM
SSC Rookie
Group: General Forum Members
Last Login: 2 days ago @ 10:32 PM
Points: 49,
Visits: 309
My company wants to create a Financial Calendar Table which contains only the Fiscal Dates. The requirements is ti populate it with the following columns:
- DateKey
- Fiscal_Year
- Fiscal_Month
- Fiscal_Week
- Fiscal Week_Start_Date
- Fiscal_Week_End_Date
The rules for these columns are:
- DateKey has to be in the format YYYYMMDD
- Weeks begin from Monday - Sunday
- Financial Year begins on 01/Jul
- Financial Week begins from Monday , which means if 01/Jul falls on any other days, then we have to take the Monday of that week as the beginning of the financial week. e.g. If 01/Jul falls on Wednesday, then the beginning of week is 29/06
Can someone help me with this script?
Post #1353313
Jeff Moden
Jeff Moden
Posted Monday, September 03, 2012 12:09 AM
SSC-Dedicated
Group: General Forum Members
Last Login: Yesterday @ 4:51 PM
Points: 32,923,
Visits: 26,811
rka (9/2/2012)
DateKey has to be in the format YYYYMMDD
In SQL Server, that's a pretty insane requirement because that would make a character based date. Since you're using SQL Server 2008, you should either use DATETIME or DATE datatypes for such a thing.
I strongly recommmend you talk to the people that designed the table and suggest that they should probably change it.
As for actually building the table... what have you tried that's not working?
--Jeff Moden
"
RBAR
is pronounced "ree-bar" and is a "Modenism" for "
R
ow-
B
y-
A
gonizing-
R
ow".
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #1353354
CELKO
CELKO
Posted Monday, September 03, 2012 8:36 PM
SSCommitted
Group: General Forum Members
Last Login: Tuesday, January 15, 2013 11:11 AM
Points: 1,945,
Visits: 2,782
>> My company wants to create a Financial Calendar Table which contains only the Fiscal Dates. <<
I hope not! Fiscal calendars have to come back to the Common Era and lawful (civil) calendars.
>> The requirements are populate it with the following columns:
- DateKey
- Fiscal_Year
- Fiscal_Month
- Fiscal_Week
- Fiscal Week_Start_Date
- Fiscal_Week_End_Date <<
Again, I hope not! The idea of a “date_key” is soooo wrong so many ways. A date is a temporal unit of measurement. The attribute property “_key” is meta data in violation of ISO-11179, basic data modeling and common sense.
Let me make a suggestion then explain it.
CREATE TABLE Fiscal_Calendar
(cal_date DATE NOT NULL PRIMARY KEY,
fiscal_date CHAR(9) NOT NULL
CHECK (fiscal_date LIKE
'[12][0-9][0-9][0-9]F[0-5][0-9]-[1-7]'),
etc);
>> DateKey [sic] has to be in the format YYYYMMDD <<
Use the calendar date. We do not care about the internal format for dates, numbers, or strings. You can use that format in the presentations layer. But the ISO-8601 format used in SQL and the rest of the ISO Standards is 'yyyy-mm-dd', so your need a good reason to go into a local dialect.
>> - Weeks begin from Monday – Sunday <<
Of course, and ISO says the days are numbered 1 to 7. That is standard.
>> - Financial Year begins on July 01.
- Financial Week begins from Monday, which means if July 01 falls on any other days, then we have to take the Monday of that week as the beginning of the financial week. e.g. If July 01 falls on Wednesday, then the beginning of week is June 29 <<
So you have a fiscal calender based on weeks. This is one of the 150+ options in the GAAP; I am not user with your narrative if you will have fiscal weeks that are not 7 days (I have seen 4 and 12 days) to align the calendar and fiscal years.
I have modified the ISO-8601 week-within-year format to use 'F' as a marker for Fiscal weeks, as opposed to the usual 'W' for calendar weeks. Thus '2012F01-1' is the first fiscal week of 2012, and a Monday. You get the parts with substrings in computed columns, VIEWs and queries.
Unfortunately, you did not define a fiscal month. In some financial calendars a month is always 30 days and a year is always 360 days with inter-calendaral days to make up the differences.
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
Post #1353682
Jason-299789
Jason-299789
Posted Tuesday, September 04, 2012 9:35 AM
SSC Eights!
Group: General Forum Members
Last Login: Wednesday, May 22, 2013 1:30 AM
Points: 803,
Visits: 2,124
Jeff Moden (9/3/2012)
rka (9/2/2012)
DateKey has to be in the format YYYYMMDD
In SQL Server, that's a pretty insane requirement because that would make a character based date. Since you're using SQL Server 2008, you should either use DATETIME or DATE datatypes for such a thing.
I strongly recommmend you talk to the people that designed the table and suggest that they should probably change it.
As for actually building the table... what have you tried that's not working?
Jeff I agree its pretty insane,
But I've seen this especially if the YYYYMMDD is converted to an INT eg 20120101 = 20,120,101.
Its been a frequent topic of discussion on various DW projects that I've worked on, prior to the Date Data type most of the calendar dims used the DateTime with the PK/SK column a CAST(CalendarDate as Int), again a pretty nasty way of doing this especially if you have a time element due to the rounding issues.
However, since 2008 I've been converted to Date Data type as the PK/SK and it seems to work very well.
_________________________________________________________________________
SSC Guide to Posting and Best Practices
Post #1353999
CELKO
CELKO
Posted Tuesday, September 04, 2012 1:17 PM
SSCommitted
Group: General Forum Members
Last Login: Tuesday, January 15, 2013 11:11 AM
Points: 1,945,
Visits: 2,782
But I've seen this especially if the YYYYMMDD is converted to an INT eg 20120101 = 20,120,101. .. , since 2008 I've been converted to Date Data type as the PK/SK and it seems to work very well.
Could be worse; I have see FLOAT, GUID and weird text strings.
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
Post #1354141
Jeff Moden
Jeff Moden
Posted Tuesday, September 04, 2012 2:17 PM
SSC-Dedicated
Group: General Forum Members
Last Login: Yesterday @ 4:51 PM
Points: 32,923,
Visits: 26,811
Jason-299789 (9/4/2012)
Jeff Moden (9/3/2012)
rka (9/2/2012)
DateKey has to be in the format YYYYMMDD
In SQL Server, that's a pretty insane requirement because that would make a character based date. Since you're using SQL Server 2008, you should either use DATETIME or DATE datatypes for such a thing.
I strongly recommmend you talk to the people that designed the table and suggest that they should probably change it.
As for actually building the table... what have you tried that's not working?
Jeff I agree its pretty insane,
But I've seen this especially if the YYYYMMDD is converted to an INT eg 20120101 = 20,120,101.
Its been a frequent topic of discussion on various DW projects that I've worked on, prior to the Date Data type most of the calendar dims used the DateTime with the PK/SK column a CAST(CalendarDate as Int), again a pretty nasty way of doing this especially if you have a time element due to the rounding issues.
However, since 2008 I've been converted to Date Data type as the PK/SK and it seems to work very well.
NP. Thanks for the feedback. I have to ask again, though... what have you tried that isn't working in your efforts to build this table?
--Jeff Moden
"
RBAR
is pronounced "ree-bar" and is a "Modenism" for "
R
ow-
B
y-
A
gonizing-
R
ow".
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #1354173
RBarryYoung
RBarryYoung
Posted Tuesday, September 04, 2012 7:46 PM
SSCrazy Eights
Group: General Forum Members
Last Login: Saturday, May 04, 2013 11:13 AM
Points: 9,855,
Visits: 9,374
Jason-299789 (9/4/2012)
Jeff Moden (9/3/2012)
rka (9/2/2012)
DateKey has to be in the format YYYYMMDD
In SQL Server, that's a pretty insane requirement because that would make a character based date. Since you're using SQL Server 2008, you should either use DATETIME or DATE datatypes for such a thing.
I strongly recommmend you talk to the people that designed the table and suggest that they should probably change it.
As for actually building the table... what have you tried that's not working?
Jeff I agree its pretty insane,
But I've seen this especially if the YYYYMMDD is converted to an INT eg 20120101 = 20,120,101.
Its been a frequent topic of discussion on various DW projects that I've worked on, prior to the Date Data type most of the calendar dims used the DateTime with the PK/SK column a CAST(CalendarDate as Int), again a pretty nasty way of doing this especially if you have a time element due to the rounding issues.
However, since 2008 I've been converted to Date Data type as the PK/SK and it seems to work very well.
A "DW" is a data warehouse which is an OLAP-type database, and these rules and keys might make sense there, because an OLAP database has different goals than an OLTP database, and thus a different (though related) modelling methodology, and therefore a different set of normal rules.
An OLAP database is designed to facilitate reporting, at the expense of other things, like diskspace and being able to maintain the data in real-time. OLTP databases on the other hand are designed to facilitate real-time data updates while insuring consistency and still be able to report on the data.
Because of these differences in goals, OLAP databases will frequently have highly redundant multi-discriminating key structures, like the one you suggest, because they can greatly facilitate reporting and summarization. But they are an anethema to an OLTP database because they introduce all kinds of problems with maintaining the consistency of the data and keys when trying to incrementally keep it up-to-date in real time.
-- RBarryYoung
,
(302)375-0451
blog:
MovingSQL.com
, Twitter:
@RBarryYoung
Proactive
Performance Solutions, Inc.
"Performance is our middle name."
Post #1354294
Jeff Moden
Jeff Moden
Posted Tuesday, September 04, 2012 10:50 PM
SSC-Dedicated
Group: General Forum Members
Last Login: Yesterday @ 4:51 PM
Points: 32,923,
Visits: 26,811
RBarryYoung (9/4/2012)
Jason-299789 (9/4/2012)
Jeff Moden (9/3/2012)
rka (9/2/2012)
DateKey has to be in the format YYYYMMDD
In SQL Server, that's a pretty insane requirement because that would make a character based date. Since you're using SQL Server 2008, you should either use DATETIME or DATE datatypes for such a thing.
I strongly recommmend you talk to the people that designed the table and suggest that they should probably change it.
As for actually building the table... what have you tried that's not working?
Jeff I agree its pretty insane,
But I've seen this especially if the YYYYMMDD is converted to an INT eg 20120101 = 20,120,101.
Its been a frequent topic of discussion on various DW projects that I've worked on, prior to the Date Data type most of the calendar dims used the DateTime with the PK/SK column a CAST(CalendarDate as Int), again a pretty nasty way of doing this especially if you have a time element due to the rounding issues.
However, since 2008 I've been converted to Date Data type as the PK/SK and it seems to work very well.
A "DW" is a data warehouse which is an OLAP-type database, and these rules and keys might make sense there, because an OLAP database has different goals than an OLTP database, and thus a different (though related) modelling methodology, and therefore a different set of normal rules.
An OLAP database is designed to facilitate reporting, at the expense of other things, like diskspace and being able to maintain the data in real-time. OLTP databases on the other hand are designed to facilitate real-time data updates while insuring consistency and still be able to report on the data.
Because of these differences in goals, OLAP databases will frequently have highly redundant multi-discriminating key structures, like the one you suggest, because they can greatly facilitate reporting and summarization. But they are an anethema to an OLTP database because they introduce all kinds of problems with maintaining the consistency of the data and keys when trying to incrementally keep it up-to-date in real time.
BWAA-HAAA!!!! Is that the long version for "storing dates as INTs or VARCHARs sucks"???
--Jeff Moden
"
RBAR
is pronounced "ree-bar" and is a "Modenism" for "
R
ow-
B
y-
A
gonizing-
R
ow".
First step towards the paradigm shift of writing Set Based code:
Stop thinking about what you want to do to a row... think, instead, of what you want to do to a column."
For better, quicker answers on T-SQL questions, click on the following...
http://www.sqlservercentral.com/articles/Best+Practices/61537/
For better answers on performance questions, click on the following...
http://www.sqlservercentral.com/articles/SQLServerCentral/66909/
Post #1354313
RBarryYoung
RBarryYoung
Posted Wednesday, September 05, 2012 5:48 PM
SSCrazy Eights
Group: General Forum Members
Last Login: Saturday, May 04, 2013 11:13 AM
Points: 9,855,
Visits: 9,374
Jeff Moden (9/4/2012)
RBarryYoung (9/4/2012)
Jason-299789 (9/4/2012)
Jeff Moden (9/3/2012)
rka (9/2/2012)
DateKey has to be in the format YYYYMMDD
In SQL Server, that's a pretty insane requirement because that would make a character based date. Since you're using SQL Server 2008, you should either use DATETIME or DATE datatypes for such a thing.
I strongly recommmend you talk to the people that designed the table and suggest that they should probably change it.
As for actually building the table... what have you tried that's not working?
Jeff I agree its pretty insane,
But I've seen this especially if the YYYYMMDD is converted to an INT eg 20120101 = 20,120,101.
Its been a frequent topic of discussion on various DW projects that I've worked on, prior to the Date Data type most of the calendar dims used the DateTime with the PK/SK column a CAST(CalendarDate as Int), again a pretty nasty way of doing this especially if you have a time element due to the rounding issues.
However, since 2008 I've been converted to Date Data type as the PK/SK and it seems to work very well.
A "DW" is a data warehouse which is an OLAP-type database, and these rules and keys might make sense there, because an OLAP database has different goals than an OLTP database, and thus a different (though related) modelling methodology, and therefore a different set of normal rules.
An OLAP database is designed to facilitate reporting, at the expense of other things, like diskspace and being able to maintain the data in real-time. OLTP databases on the other hand are designed to facilitate real-time data updates while insuring consistency and still be able to report on the data.
Because of these differences in goals, OLAP databases will frequently have highly redundant multi-discriminating key structures, like the one you suggest, because they can greatly facilitate reporting and summarization. But they are an anethema to an OLTP database because they introduce all kinds of problems with maintaining the consistency of the data and keys when trying to incrementally keep it up-to-date in real time.
BWAA-HAAA!!!! Is that the long version for "storing dates as INTs or VARCHARs sucks"???
8^Þ
(heh)
-- RBarryYoung
,
(302)375-0451
blog:
MovingSQL.com
, Twitter:
@RBarryYoung
Proactive
Performance Solutions, Inc.
"Performance is our middle name."
Post #1354960
bitbucket-25253
bitbucket-25253
Posted Wednesday, September 05, 2012 6:13 PM
SSCertifiable
Group: General Forum Members
Last Login: Today @ 9:02 AM
Points: 5,103,
Visits: 20,216
These two articles might give you a method of doing what you desire.
http://www.sqlservercentral.com/articles/function/67046/
http://www.sqlservercentral.com/articles/function/68323/
If everything seems to be going well, you have obviously overlooked something.
Ron
Please help us, help you -before posting a question please
read
Before posting a performance problem please
read
Post #1354966
« Prev Topic
|
Next Topic »
Permissions
You
cannot
post new topics.
You
cannot
post topic replies.
You
cannot
post new polls.
You
cannot
post replies to polls.
You
cannot
edit your own topics.
You
cannot
delete your own topics.
You
cannot
edit other topics.
You
cannot
delete other topics.
You
cannot
edit your own posts.
You
cannot
edit other posts.
You
cannot
delete your own posts.
You
cannot
delete other posts.
You
cannot
post events.
You
cannot
edit your own events.
You
cannot
edit other events.
You
cannot
delete your own events.
You
cannot
delete other events.
You
cannot
send private messages.
You
cannot
send emails.
You
may
read topics.
You
cannot
rate topics.
You
cannot
vote within polls.
You
cannot
upload attachments.
You
may
download attachments.
You
cannot
post HTML code.
You
cannot
edit HTML code.
You
cannot
post IFCode.
You
cannot
post JavaScript.
You
cannot
post EmotIcons.
You
cannot
post or upload images.
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved.
Privacy Policy.
Terms of Use.
Report Abuse.
