Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Fiscal Dates


Fiscal Dates

Author
Message
rka
rka
SSC Journeyman
SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)SSC Journeyman (75 reputation)

Group: General Forum Members
Points: 75 Visits: 432
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?
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)

Group: General Forum Members
Points: 52053 Visits: 40318
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 Row-By-Agonizing-Row.
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.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
Jason-299789
Jason-299789
Ten Centuries
Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)Ten Centuries (1.3K reputation)

Group: General Forum Members
Points: 1314 Visits: 3229
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
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)

Group: General Forum Members
Points: 52053 Visits: 40318
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 Row-By-Agonizing-Row.
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.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
RBarryYoung
RBarryYoung
SSChampion
SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)

Group: General Forum Members
Points: 10130 Visits: 9517
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."
Jeff Moden
Jeff Moden
SSC Guru
SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)SSC Guru (52K reputation)

Group: General Forum Members
Points: 52053 Visits: 40318
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"??? :-D

--Jeff Moden

RBAR is pronounced ree-bar and is a Modenism for Row-By-Agonizing-Row.
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.
Although they tell us that they want it real bad, our primary goal is to ensure that we dont actually give it to them that way.
Although change is inevitable, change for the better is not.
Just because you can do something in PowerShell, doesnt mean you should. Wink

Helpful Links:
How to post code problems
How to post performance problems
Forum FAQs
RBarryYoung
RBarryYoung
SSChampion
SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)SSChampion (10K reputation)

Group: General Forum Members
Points: 10130 Visits: 9517
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"??? :-D


8^Þ

(heh)

-- RBarryYoung, (302)375-0451 blog: MovingSQL.com, Twitter: @RBarryYoung
Proactive Performance Solutions, Inc.
"Performance is our middle name."
bitbucket-25253
bitbucket-25253
SSCertifiable
SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)SSCertifiable (6.2K reputation)

Group: General Forum Members
Points: 6183 Visits: 25280
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
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search