[AccessD] Re: DatePart Question

>>I do not know the bound/unbound issue
Stick around a while and you'll get to know it quite well, along with
surrogate vs natural keys, the distinction between primary and unique
keys, and a few other topics that can get very ... Er, heated? <VBG>

Charlotte Foust

-----Original Message-----
From: Robert L. Stewart [mailto:rl_stewart at highstream.net] 
Sent: Wednesday, February 04, 2004 6:30 AM
To: accessd at databaseadvisors.com
Subject: [AccessD] Re: DatePart Question


Charlotte,

You are quite correct.  A date dimension table becomes useful in a
transactional system only when you have users that need to create their
own queries against the data and they are not at the level to learn how
to do date math.  Then, they are wonderful.  Since I primarily work with
large transactional systems and data warehouses, I taught my Developer's
Workshop how to use warehousing techniques to create data marts to speed
up reporting in Access.  Once they learn the techniques, they can be
applied to any back-end database.

I do not know the bound/unbound issue, but unless we get exposure to
different techniques for doing things, we will stagnate as developers.

Robert

At 10:42 PM 2/3/2004 -0600, you wrote:
>Date: Tue, 3 Feb 2004 14:38:05 -0800
>From: "Charlotte Foust" <cfoust at infostatsystems.com>
>Subject: RE: [AccessD] Re: DatePart Question
>To: "Access Developers discussion and problem solving"
>         <accessd at databaseadvisors.com>
>Message-ID:
>
<E61FC1D4B1918244905B113C680BEA8632C44A at infoserver01.infostat.local>
>Content-Type: text/plain;       charset="us-ascii"
>
>The essential difference is that the date dimension table is generally 
>used in data warehouse applications, not in regular data entry 
>databases.  They can be useful in the latter for reporting purposes 
>only, but you can get by nicely if you've never had to slice and dice 
>very large tables based on a bunch of date criteria.  Note that fact 
>tables in a datawarehouse are usually not normalized in the same way as

>regular database tables either (they are commonly 1NF), so dimension 
>tables give you flexibility that it's hard to get any other way.  Data 
>warehousing may be slightly off-topic, but only because Access 
>developers don't have to deal with it very often.  I have, so I can 
>appreciate both sides of the discussion.
>
>Charlotte Foust
>
>-----Original Message-----
>From: DWUTKA at marlow.com [mailto:DWUTKA at marlow.com]
>Sent: Tuesday, February 03, 2004 2:05 PM
>To: accessd at databaseadvisors.com
>Subject: RE: [AccessD] Re: DatePart Question
>
>
>Nothing personal, but I have to agree with Gustav's point of view.  I 
>can see (and I believe he does too), where a table would help certain 
>situations.  However, I know first hand, the extreme lack of 
>understanding on how a date works.  I'm not saying you don't understand

>that, however, to a computer, it is MUCH faster for many functions, to 
>just let the processor do a logic operation on a number, then to have 
>it pull other data up, and compare that.  Holidays, etc, those require 
>heavier logic, so a table could be faster (depending on the amount of 
>data).
>
>I'm not knocking your approach.  But in my experience, I have never 
>needed to do anything like that.
>
>We better be careful that this doesn't turn into another bound/unbound 
>issue.
>
>Drew


_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com