I'm looking for some design advice.
I have a number of tables whose data consist of configuration details
and parameters that are incorporated into config files for various
server applications. For example, a table of customers' email address
forwarding info, so a PHP application can be used to add/modify/remove
email forwarding in a MySQL table, and a small script is used to build a
fresh sendmail virtusertable whenever there are updates to the table.
Each of the tables contains data that reflect configuration of the
servers (POP3 mailboxes, FTP users, Apache module directives, etc).
Each table has a field called "changed" which gets updated with the
current date/time every time the data is changed. Due to lack of
planning, some tables store dates as DATETIME, and others store it as
an unsigned INT containing the epoch second. I want to standardize
on one or the other, and I don't know which direction to go.
So what's the best way to store a date? I've always liked storing epoch
seconds as INTs, and leaving the translation to/from a human-readable
date up to the application, but aside from the relative unreadability of
this, are there any significant disadvantages to this method, aside from
the rollover problem in 2038? (The S32b bug?)
Would I be better off spending a few bytes extra per record and storing
things as DATETIME rather than an INT? If I'm looking at the possibily
making the application more database-portable in the future, are there
gotchas I should be aware of with any particular field types?
Paul Chvostek <[EMAIL PROTECTED]>
Operations / Abuse / Whatever
it.canada, hosting and development http://www.it.ca/
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php