Hiya. 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? Thanks. :) -- Paul Chvostek <paul@it.ca> 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
