Peter Brawley wrote,
"The earliest possible MySQL date is around 1000CE, so
you could not store geologic dates in MySQL date cols.
"Million years before present" is the geologic time
unit that would most likely cohere with other geo
databases, isn't it? Then the Cambrian would show up
around 580 mya, the beginning of recorded human
history around .005 mya, &c. A float, double or
decimal col would handle such values."
Yes, I was thinking of using decimals, especially if I
can out a way to transform them into other numbers.
For example, I might want to display "100,000 years"
rather than .1 mya in some instances.
--- Gary Richardson <gary.richardson@stripped> wrote:
> If you want to represent 290 million years as an
> integer (290,000,000):
> - An UNSIGNED INT can store 4,294,967,295
> - A UNSIGNED BIGINT can store
> In your schema, I'd use a start_period and
> end_period instead of a
> varchar. It's easier to sort and do math on.
> You could factor out 1,000,000 from your dates and
> use a float to
> represent the numbers. 290.000000 could represent
> 290 mya, while 0.01
> represents 10,000 years ago. Just make sure there is
> enough precision
> on your float.
I haven't worked with floats yet, so I don't
understand what you mean, but I'll look into it. I
could also create two columns - one with decimals
based on a billion (e.g. 1 billion = 1, while 100,000
= .1) and the other pegged to million (e.g. 1 million
= 1, and 1 billion = 1,000).
Fortunately, there aren't many geologic periods,
epochs, etc. to work with, so this shouldn't be too
Thanks for all the tips!
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around