December 17, 2008 at 9:37 am
Jeff Moden (12/17/2008)
Brandon,Not sure what the text editor you used may have done to you, but there's a lot of missing spaces in your code... for example CREATE TABLE has become CREATETABLE and SET @variable has become SET@variable. There are many other accidental concatenations throughout the code. It might be why there's not much discussion or rating on this article, so far... people just don't wanna take the time to fix posted code.
The "Text Editor" I used was SQL Server Management Studio for all SQL Code. The tested and working code was then copied into the article which is a word document typed in OpenOffice. I then emailed the entire DOC file to Steve so it is something in the publishing that is causing it.
Also, you may want to add a link to your article on how to build your numbers table... it would help people that just don't know about such things, a lot. Either that, or it's short enough to just use in the code.
Good idea. When I submitted this one, the first hadn't been published yet for me to include the link. I will have to go back and do it now.
Contact Steve Jones for how to edit your article if you're interested in doing such a thing. It's not difficult and Steve is very happy to help on these things.
Great idea and I will do that and fix them both up because this happened with the first one too.
December 17, 2008 at 9:39 am
rkonopka (12/17/2008)
Instead of double converting (first to varchar then back to datetime), wouldn't it be simpler and "cleaner" to do this:select dateadd(dd,datediff(dd,0,getdate()),0)
Enjoyed the article
I've started to use that approach for time stripping but this article was written before I adopted that method. Thanks for the input!
December 17, 2008 at 11:21 am
CheeseMan316 (12/17/2008)
mike.byrnes (12/17/2008)
If my calculations are correct, then if each year took 5Mb then 200 years would be 1 Gb worth of data, not 100Mb.I guess I was incorrect that it's 500KB per year then because here is the space used by my table.
name rows reserved data index_size unused
-------------------- ----------------- -------- ---------- ------------------
util_time_coordinate 1829625 99792 KB 52400 KB 47296 KB 96 KB
It is customary and useful to have your int date keys be formatted CCYYMMDD, at least in the classical date dimension scenario. Identities are really not helpful here.
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
December 17, 2008 at 1:32 pm
I've worked with a dates table to find "missed" days, and also used CTES to generate sets of dates on the fly using a tally table to increment some number of days from a given starting date. Obviously having a single date column and a single clustered index require less disk space, and the cte approach required next to nothing in disk, although you pay for it in CPU cycles. But your table extends the concept to hours, months, and quarters. Could you give us a real world example or two using other dimensions besides day?
__________________________________________________
Against stupidity the gods themselves contend in vain. -- Friedrich Schiller
Stop, children, what's that sound? Everybody look what's going down. -- Stephen Stills
December 17, 2008 at 2:30 pm
Bob Hovious (12/17/2008)
Could you give us a real world example or two using other dimensions besides day?
I have worked with large data warehouse applications that do a lot of data aggregation. The ability to roll data up into non-day increments (hours, months, quarters and years) is useful in those applications. It allows you to store the aggregated data referenced by a single time coordinate. I'm not suggesting that a set of data be linked to ALL dimensions. So you wouldn't link a record to the year 2008, Quarter 1, Month 10 and day 10 if it was 10-OCT-2008. But if you do periodical aggregation as the need for granularity decreases as data ages, the ability to use a single value to represent that can be useful.
December 17, 2008 at 2:31 pm
TheSQLGuru (12/17/2008)
It is customary and useful to have your int date keys be formatted CCYYMMDD, at least in the classical date dimension scenario. Identities are really not helpful here.
What format would you propose for the quarterly and hourly values?
December 18, 2008 at 8:20 am
I had zoned out when I posted that this date table is more granular than day. :hehe:
Best,
Kevin G. Boles
SQL Server Consultant
SQL MVP 2007-2012
TheSQLGuru on googles mail service
December 22, 2008 at 10:08 am
Here is another approach on the link below. Function F_TABLE_DATE is a multistatement table-valued function that returns a table containing a variety of attributes of all dates from @FIRST_DATE through @LAST_DATE. It was intended mainly to be able to load a date table, but is can also be used directly in a statement for those occasions when you want to go outside your standard ranges.
This function has about 65 columns representing just about every date attribute I have ever had any need for. It does not include any Fiscal period attributes, since that is something that is usually specific to a particular organization.
Date Table Function F_TABLE_DATE
Viewing 8 posts - 16 through 22 (of 22 total)
You must be logged in to reply to this topic. Login to reply