Почему не используете TIMESTAMP?

Господа, я как заказчик неоднократно в реализованных проектах встречаю использование для хранения дат в бд mysql тип int,
спрашивается почему не используете TIMESTAMP специально предназначенного для этого ?

По мне так зачастую в бд приходится вносить изменения из соответствующих редакторов, и с датами в int очень сложно работать/править. Вы об этом думаете?

Цитата:

TIMESTAMP
Хранит 4-байтное целое число, равное количеству секунд, прошедших с полуночи 1 января 1970 года по усреднённому времени Гринвича (т.е. нулевой часовой пояс, точка отсчёта часовых поясов). При получении из базы отображается с учётом часового пояса. Часовой пояс может быть задан в операционной системе, глобальных настройках MySQL или в конкретной сессии. Запомните, что сохраняется всегда количество секунд по UTC (универсальное координированное время, солнечное время на меридиане Гринвича), а не по локальному часовому поясу.

(c)посилання

Использую DATETIME и INT.
Соответствующие редакторы это phpMyAdmin?

Цитата ("nolesxp"):

По мне так зачастую в бд приходится вносить изменения из соответствующих редакторов, и с датами в int очень сложно работать/править. Вы об этом думаете?

Вам видимо gui плохой делают в движках, раз так часто в базе ковыряетесь. Работа с timestamp требует каждый раз проводить конвертирование в тот же int и обратно.

посилання

Насчет gui , не всегда оно и нужно, а править записи иногда приходится. Зачем конвертировать в int и обратно, зачастую дата используется, для указания даты записи или даты обновления этой записи. По ссылке ничего вразумительного, я уже ее читал.

Насчет отображения с учетом часового пояса, это даже плюс возможно даже в большенстве случаев.

Цитата ("nolesxp"):

TIMESTAMP специально предназначенного для этого ?

Вам пытались сказать, что TIMESTAMP - это и есть целое число, некое число секунд, непонятно как считаемых.
Дата хранится в виде целого числа.

Однако ничего не мешает использовать формат DATETIME тогда дата будет в виде 2010-03-23 18:14:45

Цитата ("nolesxp"):

Зачем конвертировать в int и обратно

Самая базовая функция php по работе со временем time() возвращает время в int, поэтому - конвертирование. Все операции, к примеру высчитывание разницы между двумя моментами времени проводятся в формате int. В общем все, что делается, быстрее и эффективнее делать в виде int, т.к. конвертирование требуется только один раз, при выводе, причем очень удобной функцией date(формат, дата).

Int проблем с часовыми поясами также не вызывает. Просто используйте phpmyadmin и другие средства для тех целей, для которых они созданы. Для остальных есть админка ваших проектов.

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

Цитата ("nolesxp"):

спрашивается почему не используете TIMESTAMP специально предназначенного для этого ?

Цитата ("nolesxp"):

я думаю что в базе должно лежать то что отражает название поля, а именно дата а не int

Эммм, я чего-то не понимаю?

Цитата ("nolesxp"):

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

Вообще-то название поля должно отражать то, что в нем хранится. Я не зря привел вам пример с кодировкой. Использование int равносильно использованию юникода. Удобно, универсально.

Просто ответьте на один вопрос: зачем использовать медленное представление данных? Вообще, для чего?

Цитата ("Lisio"):

Вообще-то название поля должно отражать то, что в нем хранится.

Ну наверное не совсем так. Тип поля должен соответствовать тому, что там хранят и содержимое поля тоже. Где то были эти рекомендации или требования... кажется в нормальных формах описано что где должно быть.
Цитата:

зачем использовать медленное представление данных? Вообще, для чего?

хоть вопрос и не ко мне. далеко не все определяется скоростью. всегда есть некоторый компромисс между скоростью работы и удобством, стоимостью эксплуатации и поддержки и так далее. скорость это еще не все.

Цитата ("frig"):

Ну наверное не совсем так. Тип поля должен соответствовать тому, что там хранят и содержимое поля тоже. Где то были эти рекомендации или требования... кажется в нормальных формах описано что где должно быть.

Мы говорим о названии поля. Что касается соответствия типа содержимому, то мне не понятно, чем плох целочисленный тип для целочисленных данных?

Цитата:

Мы говорим о названии поля. Что касается соответствия типа содержимому, то мне не понятно, чем плох целочисленный формат для целочисленных данных?

Разве только о названии? Когда целочисленный тип и целочисленное содержимое, то все нормально. А если тип целочисленный, а там дата, еще и поди угадай в каком формате - это уже несколько не то.

это, походу таблица будет даже не в первой нормальной форме.

Цитата ("frig"):

Разве только о названии?

Да, цитирую: Цитата ("nolesxp"):

Не убедили, я думаю что в базе должно лежать то что отражает название поля

Цитата ("frig"):

А если тип целочисленный, а там дата

UNIX time - целочисленные данные.

Цитата ("Lisio"):

Да, цитирую:

Это мысли ТС, а я уже дальше говорю, что
Цитата ("frig"):

Тип поля должен соответствовать тому, что там хранят и содержимое поля тоже.

Цитата ("Lisio"):

UNIX time - целочисленные данные.

Верно, но для базы это не дата и не время. Это int, который потом надо интерпретировать. Это не страшно и не самый худший вариант, но почти с тем же успехом можно дату записывать прописью и писать в поле varchar.

Цитата ("frig"):

Это int, который потом надо интерпретировать.

А timestamp - это text ?

Цитата ("Lisio"):

А timestamp - это text ?

а почему бы и нет? цифры также можно хранить в поле varchar. почему нет?
можно даже что бы наверняка взять text. да и зачем привязывать себя к timestamp? можно записать прописью, или в своем личном формате. Никто ж не мешает. Какой нить формат по предоставлению в буквенной интерпретации еще и компактнее получится.

Ну так зачем использовать timestamp? Давайте пользоваться longblob, раз уж пошла такая пьянка. Чего мелочиться?