Kosenko Max wrote:
>
>
> I think it's better to try go with single integer. It perfectly fits range
> 12:00:00 midnight, January 1, 0001 Anno Domini (Common Era) to 11:59:59
> P.M., December 31, A.D. (C.E.) in 100 nanosecond units. And it's good
> idea to store all dates in UTC.
>
> Why
Simon Slavin-2 wrote:
>
>
> We can't give you much idea because . . .
> Another aspect is which fields you need to retrieve when you do your
> SELECT. If your select needs to retrieve the time field, and the time
> field doesn't appear in the index it's using, it will need to read the
>
danjenkins wrote:
>
> Hello,
> We use a julian.decimal format to represent date/time (i.e. noon of August
> 26, 2009 would be 40049.5000) and we use this julian date for an index
> key. Our databases are frequently up to 3GB in size containing 10 million
> records with 15 assorted field types p
On 27 Aug 2009, at 3:21am, danjenkins wrote:
> We use a julian.decimal format to represent date/time (i.e. noon of
> August
> 26, 2009 would be 40049.5000) and we use this julian date for an
> index key.
> Our databases are frequently up to 3GB in size containing 10 million
> records
> with
On Wed, Aug 26, 2009 at 9:21 PM, danjenkins wrote:
>
> Hello,
> We use a julian.decimal format to represent date/time (i.e. noon of August
> 26, 2009 would be 40049.5000) and we use this julian date for an index key.
> Our databases are frequently up to 3GB in size containing 10 million records
> w
Hello,
We use a julian.decimal format to represent date/time (i.e. noon of August
26, 2009 would be 40049.5000) and we use this julian date for an index key.
Our databases are frequently up to 3GB in size containing 10 million records
with 15 assorted field types per record and contain 6 months o
6 matches
Mail list logo
