[AccessD] Re: DatePart Question

Drew,

Actually you are way off.  ;-)  The data warehouses I deal with are multi 
terrabyte.  Think about performing a function on 200 million rows, one row 
at a time, versus joining to a table that has it done already.  Sorry guy, 
but it is a no-brainer in warehousing.

Now, for creating a simplified interface for end users that want to do 
queries and not learn VBA, it is also great.

Other than those two uses, it is a personal preference.  My preference is 
to create the function to populate the data and not do date math.

Robert

At 04:29 PM 2/4/2004 -0600, you wrote:
>Date: Wed, 4 Feb 2004 12:45:07 -0600
>From: DWUTKA at marlow.com
>Subject: RE: [AccessD] Re: DatePart Question
>To: accessd at databaseadvisors.com
>Message-ID:
>         <2F8793082E00D4119A1700B0D0216BF802227832 at main2.marlow.com>
>Content-Type: text/plain;       charset="iso-8859-1"
>
>I understand more 'complex' date 'info', such as holidays, fiscal period,
>etc.  I still don't understand the reason for basic date information, such
>as day, month, year, day of week, etc.  I have never actually run any tests,
>but my gut says that a query where I wanted all records in the month of May
>(ANY year), that if I put Month([MyDateField])=5 in the Where clause, that
>it would be faster then having a relationship to a date dimension table.
>
>Data entry, or data warehousing, the speed should still be a factor,
>correct? Or am I way off on my gut feeling (really too busy to build an
>appropriate test.)
>
>Drew