--- On Wed, 16/1/08, Zak B. Elep <[EMAIL PROTECTED]> wrote:
> From: Zak B. Elep <[EMAIL PROTECTED]>
> Subject: Re: [plug] Large MySQL table
> To: "Philippine Linux Users' Group (PLUG) Technical Discussion List"
> <[email protected]>
> Date: Wednesday, 16 January, 2008, 6:16 PM
> On Jan 16, 2008 5:40 PM, Robert Locke <[EMAIL PROTECTED]>
> wrote:
> > > So in my case since I have a lot of functions
> that deal with dates i
> > > would need at least two int columns to replace
> the date column. Is
> > > this the widely accepted industry practice?
> >
> > I can't speak authoritatively on industry practice
> but we've been able
> > to get away with just using indexed datetime columns
> without the need
> > to create (additional) "int" columns...
>
> How about using epochs in an int column to express dates,
> then using
> either your database's datetime converter builtins or
> your language's
> own converters?
>
> Cheers,
>
> Zakame
>
My rule of thumb is to avoid functions in sql statements as much as possible,
escpecially when querying huge tables. In your case, indexing the date field
should be enough when paired with a BETWEEN operator, as somebody suggestion
earlier in the thread.
--- mike t.
_________________________________________________
Philippine Linux Users' Group (PLUG) Mailing List
[email protected] (#PLUG @ irc.free.net.ph)
Read the Guidelines: http://linux.org.ph/lists
Searchable Archives: http://archives.free.net.ph
