DATETIME or INT ?

Mosik

Новичок
DATETIME or INT ?

Все время держал дату в формате DATETIME. Но постоянно приходилось ее конвертить в метку времени (timestamp) а потом к тому виду, который хочется.

Вчера посмотрел в каком формате держат дату разработчики продуктов phpBB, osCommerce и echoArticles. Они все держат время в поле типа INT!

Вот и думаю. Не с балды же ведь разработчики БД реализовали типы данных даты и времени. Так почему многие держат в INT?

Я понимаю что это личный выбор каждого разработчика, в каком формате держать дату. Вот и прошу высказаться по этому поводу. (в поиске был)

Прошу высказаться кто в каком формате держит дату в БД и аргументировать свой выбор.
 

PILOT

Новичок
неважно как держать в базе, но в php все операции производить с unixtime.
 

Kelkos

Сам себе программер
Если ты не подразумеваешь вести базу "ручками", то формат time удобнее.
Если предполагается, что в этой базе тебе придётся много работать непосредственно с данными, то тебе было бы удобнее работать с "человеко понятным" временем.
 

Mosik

Новичок
Kelkos
Данные из базы будут вытягивать скрипты. Вручную править непосредственно в БД ничего не планируется.

Для примера возьмем скрипт каталога статей (можно каталог сайтов, фотографий, неважно чего).
В таблице статей есть поле "Дата публикации". Скрипт будет вытягивать данные с таблицы и показывать посетителю. Дату нужно преобразовать к человекоподобному виду в нужном формате. Но в админке нужно эти статьи править (добавлять). И там, к примеру, дата будет вводиться (изменяться) админом как отдельно день, месяц и год.
 

SelenIT

IT-лунатик :)
>Но постоянно приходилось ее конвертить в метку времени (timestamp) а потом к тому виду, который хочется

Зачем? Не с балды же разработчики БД реализовали кучу функций данных даты и времени, например DATE_FORMAT...
 

Skubent

Новичок
Задача "найти все записи, созданные в мае" быстрее решается с форматом DATETIME.
Задача "отсортировать записи по времени создания" быстрее решается с timestamp.

Знаем, что нам делать == знаем, какой тип применять.
 

SelenIT

IT-лунатик :)
>Задача "отсортировать записи по времени создания" быстрее решается с timestamp.
Намного быстрее?
 

Skubent

Новичок
При прямом подходе - на время конвертации DATETIME в INT.
При кривом подходе - на время (время сравнения строки - время сравнения целого).
 

SelenIT

IT-лунатик :)
Skubent
Ты уверен, что при сортировке DATETIME без каких-либо преобразований сравниваются строки?
 

Mosik

Новичок
Skubent
Очень сомневаюсь что там сравниваются строки
 

SelenIT

IT-лунатик :)
Skubent
Ну, при кривом подходе можно и int-ы сортировать как строки, так что это не аргумент...

-~{}~ 06.07.06 19:21:

Из любопытства провел беглый тест (20 тыс. записей, MySQL 5.0.22, WinXP). Без индексов int сортируется в среднем на 25-30% быстрее, чем datetime, с индексами разница практически не заметна. Имхо, результат вполне ожидаемый. А вариант с "конвертацией DATETIME в INT" (ф-цией UNIX_TIMESTAMP) еще вдвое медленнее.
 

Skubent

Новичок
Думается мне, с индексами разница станет заметна при большем количестве записей.

Когда я говорил про конвертацию, подразумевал, что timestamp - чистый int, а datetime - не совсем, хотя, конечно, для 100% ответа надо исходники читать...
 

Mosik

Новичок
Почитал вчера комментарии тут и на других форумах и почти согласился с мыслью что буду держать дату в DATETIME.

А потом меня посетила следующая мысль:
У меня есть класс, который отвечает за работу с таблицей статей (продуктов, сайтов, нет значения чего...). В нем есть метод getItem, который возвращает массив с данными статьи. Везде в коде проэкта я вызываю данный метод объекта для получения элемента. Зачем думаю объяснять не стоит.

Так вот, в разных местах проэкта мне может понадобиться дата в разных форматах. И использовать функции mySQL тут уже не получится так как запрос к БД идет в методе getItem, который для всего проэкта один.

Получается что в данном случае целесообразней дату хранить как INT и средствами PHP ее конвертить в любой формат?
Какие будут мысли по этому поводу?
 

SelenIT

IT-лунатик :)
Может, есть смысл ввести в этот класс специальное свойство, определяющее формат даты в запросе?
 

Mosik

Новичок
Ну а если полей с типом ДАТА несколько и нужны разные форматы в зависимости от поля?
 
Сверху