datetime, timestamp, etc. против unixtime в поле int

В web-приложениях, использующих СУБД MySQL, для хранения даты и/или времени можно:

1. использовать специальные календарные типы данных(datetime, date, time, timestamp, year)
2. завести поле с типом INT и вставлять дату/время в UNIXTIME
3. ну и ещё для кучи — в поле текстового типа хранить дату с своём формате(но это как то айс))

Опишем плюсы и минусы первого варианта, после анализа которых и будут видны минусы использования второго варианта.

Плюсы первого варианта:

1. В базе данные даты хранятся компактно. В виде чисел. Формат вида ГГГГ-ММ-ДД ЧЧ:ММ:СС создаётся на лету при запросе.
2. При занесении данных MySQL пытается разными способами интепретировать полученную дату(т.е. формат даты может быть достаточно вольным, однако надо придерживаться некоторых правил), при выборке MySQL автоматически преобразовывает дату в определённую форму, что может быть удобно.
3. Есть куча функций для работы с календарными типами данных MySQL.  Это: 1) снимается нагрузку с web-приложения; 2) Упрощает разработку web-приложения.
4. с timestamp работать очень удобно. Если не указать его явно, то в поле будет автоматически вставляться текущая дата при вставке и обновлениии записи.
5. возможность задать дату в более широком диапазоне(в типе DATETIME, DATE), чем если бы добавляли UNIXTIME в INT поле.
6. при использовани поля с типом TIMESTAMP дата возращается клиенту с учётом его часового пояса, при занесении даты в поле такого типа дата так же корректируется на UTC/GMT+0 относительно пояса клиента. Достаточно доходчиво об этом написано здесь http://habrahabr.ru/blogs/mysql/69983/.

Минусы:

1. MySQL не проверяет дату на корректность. Точнее СУБД проверяет, к примеру, чтобы месяц был от 1 до 12, день месяца от 1 до 31. Но можно занести некорректную дату, к примеру 2010-02-31. Ведь в феврале нет 31-го дня. Но это уже вопрос к web-приложению, поставляющему данные.

Рассмотрим второй вариант.

Плюсы:

1. Переносимость между различными СУБД. Целочисленный тип есть во всех СУБД, в отличии от календарного. Или же если он(календарный тип) и есть в другой СУБД, то может быть несовместимость. Хотя если нормально экспортировать базу с календарными типами, выбрав опцию ‘совместимость дампа с такой то СУБД’, то проблем быть не должно.

Минусы(по сути отсутствие плюсов от первого варианта — это и есть большой минус второго):

1. ручная обработка данных, средствами web-приложения.
2. нагрузка по обработке данных переходит на web-приложение.
3. чем больше код(код для обработки данных), тем больше ошибок, тем сложнее разрабатывать и поддерживать продукт.
4. хранение даты в малом диапазоне.
5. работу с часовыми поясами придётся возложить на web-приложение.

Про третий вариант я молчу. Это просто не дело. Ведь должна же быть среди разработчиков хоть какая то договорённость. А хранить дату в своём формате это плохо. С датой в таком виде(в текстовом поле) многое придётся делать самому: преобразование, сортировка и т.д. Функции для работы с датами не будут работать с этими данными.

По логике вещей календарные типы придуманы не зря и использовать нужно именно их. Не надо забивать гвозди лопатой.