| |
|
|
| | в общем всегда хранил используя стандартные типы данных для даты. но вот подсмотрел в cms joomla и увидел такой формат. собственно, в чем плюсы и минусы хранения даты в таком виде? по идее, для использования таких функций, как например TO_DAYS и т.п придётся прямо в запросе преобразовывать постоянно с помощью функции FROM_UNIXTIME ?
хотелось бы узнать мнение более опытных разработчиков. спасибо | |
| |
|
|
| |
автор: qwqasdasdasdasdasdasdasdasdad (30.03.2010 в 10:43) |
|
| |
для: psychomc
(30.03.2010 в 10:25)
| | | int(14)? o_O | |
| |
|
|
| |
|
|
| |
для: qwqasdasdasdasdasdasdasdasdad
(30.03.2010 в 10:43)
| | | хм, ошибся, int(11) | |
| |
|
|
| |
|
|
| |
для: psychomc
(30.03.2010 в 10:25)
| | | Плюс в индексировании и сортировке, обычные календарные типы очень плохо сортируются и индексируются - при больших объёмах информации происходят затыки. Мы например, год назад скакали с этим форумом переделывая DATETIME на INT. Хотя, конечно, если основной упор на вычисление разницы во времени - календарные типы и множество MySQL-функций гораздо удобнее. | |
| |
|
|
| |
|
|
| |
для: cheops
(30.03.2010 в 12:55)
| | | спасибо большое за развёрнутый ответ. буду переходить потихоньку :) | |
| |
|
|
| |
|
|
| |
для: cheops
(30.03.2010 в 12:55)
| | | Плюс еще и в том, что INT-представление - регион-независимо. В двух смыслах. Не навязывается стиль написания даты. Не навязываются таймзона и правила летнего времени MySQL-сервера. | |
| |
|
|
| |
|
|
| |
для: Trianon
(30.03.2010 в 13:09)
| | | убедили окончательно ;) | |
| |
|
|
