-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
MySQL. В каком формате лучше хранить время создания записи?
- Автор темы IF
- Дата начала
que_bunt
Новичок
Andreika иногда надо сделать выборку по дню,месяцу,году или например выбрать только уникальные год+месяц.
вобщем много, так что лучше делать формат поля даты именно тот который для него закладеный разработчиками наслаждатся простотой использования функция для работы з датой-времям (раздел мануала MySQL - Date & Time Functions)
заметь, я не говорю не использовать TIMESTAMP, это уже кому как нравится, я об использовании varchar & int.
вобщем много, так что лучше делать формат поля даты именно тот который для него закладеный разработчиками наслаждатся простотой использования функция для работы з датой-времям (раздел мануала MySQL - Date & Time Functions)
заметь, я не говорю не использовать TIMESTAMP, это уже кому как нравится, я об использовании varchar & int.
Andreika
"PHP for nubies" reader
потому, что
Storage Requirements
DATETIME 8 bytes
INT, INTEGER 4 bytes
потому, что TIMESTAMP слишком умная
потому, что я храню метку создания записи, а не некую дату
потому, что мне ничем не сложнее выбрать записи за 22 марта 2001 года если это будет UNIX_TIMESTAMP, а не DATETIME
потому, что в php удобнее работать с int а не с неким DATETIME, о котором php не слихивал
хватит?
а почему ж ты используешь DATETIME ?
Storage Requirements
DATETIME 8 bytes
INT, INTEGER 4 bytes
потому, что TIMESTAMP слишком умная
потому, что я храню метку создания записи, а не некую дату
потому, что мне ничем не сложнее выбрать записи за 22 марта 2001 года если это будет UNIX_TIMESTAMP, а не DATETIME
потому, что в php удобнее работать с int а не с неким DATETIME, о котором php не слихивал
хватит?
а почему ж ты используешь DATETIME ?
que_bunt
Новичок
>потому, что TIMESTAMP слишком умная
в каком смысле?
>потому, что я храню метку создания записи, а не некую дату
как ты уже писал - "что по сути одно и тоже"
>потому, что мне ничем не сложнее выбрать записи за 22 марта 2001 года если это будет UNIX_TIMESTAMP, а не DATETIME
а если надо выбрать записи между 22 марта 2001 и текущем днем например? или все уникальные год+месяц в базе (типа: 01.2001, 02.2002, ..., 04.2006)
>потому, что в php удобнее работать с int а не с неким DATETIME, о котором php не слихивал
с инт может и удобней работать, но используя те же хваленые ф-и для работы с датой-временем, можно вобще исключать обработку в пхп.
>а почему ж ты используешь DATETIME ?
+ мне так удобней, и как показывает моя практика - ефективней.
а вот насчет Storage Requirements - это интересный факт, даже не задумывался об этом.
в каком смысле?
>потому, что я храню метку создания записи, а не некую дату
как ты уже писал - "что по сути одно и тоже"
>потому, что мне ничем не сложнее выбрать записи за 22 марта 2001 года если это будет UNIX_TIMESTAMP, а не DATETIME
а если надо выбрать записи между 22 марта 2001 и текущем днем например? или все уникальные год+месяц в базе (типа: 01.2001, 02.2002, ..., 04.2006)
>потому, что в php удобнее работать с int а не с неким DATETIME, о котором php не слихивал
с инт может и удобней работать, но используя те же хваленые ф-и для работы с датой-временем, можно вобще исключать обработку в пхп.
>а почему ж ты используешь DATETIME ?
+ мне так удобней, и как показывает моя практика - ефективней.
а вот насчет Storage Requirements - это интересный факт, даже не задумывался об этом.
sani
Новичок
Всё же в итоге получается, что некого особого приемущества int'a перед datetime'ом нет так же, как и наоборот...
Результат, на вкус и цвет - товарища нет. Кто хочет, тот то и будет использовать. В конце концов, если человек работал с int'ом долгое время и это его устраивало, логично, что он не будет далее использовать некую другую форму хранения данных времени.
Результат, на вкус и цвет - товарища нет. Кто хочет, тот то и будет использовать. В конце концов, если человек работал с int'ом долгое время и это его устраивало, логично, что он не будет далее использовать некую другую форму хранения данных времени.
SelenIT
IT-лунатик :)
>потому, что Storage Requirements...
И какую погоду сделают эти 4 байта/запись при наличии хотя бы пары-тройки полей а-ля VARCHAR(255)?
>потому, что в php удобнее работать с int а не с неким DATETIME, о котором php не слихивал
А часто ли вообще нужно "работать" с датой именно в PHP, если львиную долю форматирования и т.п. можно сделать функциями самой базы? Кстати, в случае DATETIME для этого нужно на одну операцию меньше
>почему ж ты используешь DATETIME ?
Хотя бы за возможность хранить даты до 1970 и после 2037 гг. - кто его знает, сколько там проживет моя программа...
И какую погоду сделают эти 4 байта/запись при наличии хотя бы пары-тройки полей а-ля VARCHAR(255)?
>потому, что в php удобнее работать с int а не с неким DATETIME, о котором php не слихивал
А часто ли вообще нужно "работать" с датой именно в PHP, если львиную долю форматирования и т.п. можно сделать функциями самой базы? Кстати, в случае DATETIME для этого нужно на одну операцию меньше
>почему ж ты используешь DATETIME ?
Хотя бы за возможность хранить даты до 1970 и после 2037 гг. - кто его знает, сколько там проживет моя программа...
que_bunt
Новичок
sani послушай Фаната, он знает намного больше меня:
или разработчики MySQL тип DATATIME всунули от нефиг делать?
з.ы.: это все конечно же мое ИМХО.
-~{}~ 08.05.06 21:51:
да про хранение даты до 1970 я вообще забыл...
поэтому для хранения даных определенного типа лучше использовать те типы полей что придусмотрены разработчиками.
или разработчики MySQL тип DATATIME всунули от нефиг делать?
з.ы.: это все конечно же мое ИМХО.
-~{}~ 08.05.06 21:51:
да про хранение даты до 1970 я вообще забыл...
Andreika
"PHP for nubies" reader
SelenIT
для этого нужно на одну операцию меньше
в пхп или вообще? )
хранить даты до 1970 и после 2037 гг
угу.. интересная возможность... момент времени не может быть меньше 2006 года ) а про после2037 поговорим в году так 2027ом
que_bunt
или разработчики MySQL тип DATATIME всунули от нефиг делать?
ну в таком случае UNIX_TIMESTAMP точно придумали от нефик делать?
как ты уже писал - "что по сути одно и тоже"
int - служебное поле, хранящее момент создания записи, с которым не производятся (в тч в выборках) никакие операции, кроме форматирования даты... если тебе постоянно очень надо посчитать в какой день недели за прошлый год было записано больше логов - используй DATETIME (хотя и с int в этом случае прожить, конвертировав его DATETIME в самом запросе - не думаю, что вызов нужной функции займет подавляющее время запроса).. где мне оно не нужно - я использую int, соответстно если нужна дата использую DATE(TIME)
sani
они не конкуренты вообще-то... если те нужна дата, если ты помнишь, что в месяцах разное кол-во дней, а год бывает високосным - используй DATETIME )
для этого нужно на одну операцию меньше
в пхп или вообще? )
хранить даты до 1970 и после 2037 гг
угу.. интересная возможность... момент времени не может быть меньше 2006 года ) а про после2037 поговорим в году так 2027ом
que_bunt
или разработчики MySQL тип DATATIME всунули от нефиг делать?
ну в таком случае UNIX_TIMESTAMP точно придумали от нефик делать?
как ты уже писал - "что по сути одно и тоже"
int - служебное поле, хранящее момент создания записи, с которым не производятся (в тч в выборках) никакие операции, кроме форматирования даты... если тебе постоянно очень надо посчитать в какой день недели за прошлый год было записано больше логов - используй DATETIME (хотя и с int в этом случае прожить, конвертировав его DATETIME в самом запросе - не думаю, что вызов нужной функции займет подавляющее время запроса).. где мне оно не нужно - я использую int, соответстно если нужна дата использую DATE(TIME)
sani
они не конкуренты вообще-то... если те нужна дата, если ты помнишь, что в месяцах разное кол-во дней, а год бывает високосным - используй DATETIME )
sani
Новичок
que_bunt
Ты думаешь так просто перейти с int'a на datetime? Сам суди, я пол года уже использую int, и соответственно все классы которые я писал тоже основанны на int'e... Конечно классы рано или поздно я буду обнавлять, дополнять, но пока проблемы с int'ом не возникнет, буду работать с ним
Andreika
Твои факты весьма меня удовлетворили, но пока мне не приходилось работать так глубоко, что надо было искать - високосный определённый год или нет... Конечно есть и много других задач, кроме как високосный год, я же это понимаю...
В итоге вы меня уговорили... убидили... Буду в дальнейшем использовать datetime...
Ты думаешь так просто перейти с int'a на datetime? Сам суди, я пол года уже использую int, и соответственно все классы которые я писал тоже основанны на int'e
... Конечно классы рано или поздно я буду обнавлять, дополнять, но пока проблемы с int'ом не возникнет, буду работать с ним Andreika
Твои факты весьма меня удовлетворили, но пока мне не приходилось работать так глубоко, что надо было искать - високосный определённый год или нет... Конечно есть и много других задач, кроме как високосный год, я же это понимаю...
В итоге вы меня уговорили... убидили... Буду в дальнейшем использовать datetime...
