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 <[EMAIL PROTECTED]> 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 > 18,446,744,073,709,551,615 > > 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 hard. Thanks for all the tips! __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com -- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
