Как лучше хранить дату и время в MySQL?

[untied]

Как лучше хранить дату и время в MySQL?

Я всегда храню в виде метки, полученной ф-ей time() (поле в таблице имеет тип BIGINT). Записи без проблем сортируются по дате и времени, а при выводе в html-страницу такую метку несложно отформатировать по вкусу ф-ей date().

Но может логичнее использовать специальные типы MySQL? И почему?

Тип DATE, к примеру, занимает всего 3 байта. То есть если известно абсолютно точно, что для каждой записи нужно хранить только дату (а время не имеет значения), то можно сэкономить место.

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

 

[Кром]

Я храню время в datetime (публикация новостей, статей, статистика, системное время и т.д.), а в php преобразую к нужному виду.
И прекрасно себя чувствую.

 

[untied]

А как из DATETIME переводишь в удобочитаемый вид (т.е. такой, который нужен именно в этом приложении и в этом контексте)?
Оно же выдается в виде 'YYYY-MM-DD HH:MM:SS'

 

[Frol]

hint: в MySQL есть функции для работы с датой.

 

[ecto]

храню в поле типа int, при выводе использую date()
разные заказчики хотят разные форматы времени.

 

[tony2001]

http://dev.mysql.com/doc/mysql/ru/date-and-time-functions.html

 

[ecto]

вот никак не могу придумать способа перевода пользовательского формата времени в mysql(YYYY-MM-DD HH:MM:SS) или timestamp.
кроме как прямого парсинга ничего не приходит в голову,
strtotime не подходит из-за English textual datetime description.

 

[Фанат]

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

 

[Фанат]

untied

BIGINT

ты бы ещё в longblob хранил, и парился на тему объема.

моё мнение - хранить можно в чем угодно, поскольку функции для перевода между форматами существуют.

Меня немного раздражает длинная колбаса date_format в запросах, поэтому я предпочитаю юникстайм для тех случаев, для которых он подходит.

 

[Кром]

На самом деле, за datetime - будущее. То что в php нет надлежащей функции для парсинга этого формата, это вопрос времени.
Меня тоже раздражает date_time, поэтому на php написал свой вариант (а-ля date() но подходит для всех вариантов временных полей в mySQL).

 

[Фанат]

Я тоже написал!
Вот только работает она путем перевода из мускуля... в юникс )))

 

[alexhemp]

Фанат

Я храню в DATETIME а в запросах использую ф-цию UNIX_TIMESTAMP

 

[untied]

Originally posted by Frol
hint: в MySQL есть функции для работы с датой.

Frol, спасибо, я в курсе. В MySQL действительно есть встроенные функции для преобразования меток времени, только sql-запрос от их использования проигрывает и в читаемости и в длине.

Всем спасибо! Значит мой вариант работы со временем вполне имеет право на существование. BIGINT + date() рулят.

 

[Frol]

А как из DATETIME переводишь в удобочитаемый вид (т.е. такой, который нужен именно в этом приложении и в этом контексте)?

hint: в MySQL есть функции для работы с датой.

Frol, спасибо, я в курсе. В MySQL действительно есть встроенные функции для преобразования меток времени, только sql-запрос от их использования проигрывает и в читаемости и в длине.

м-да.
он в курсе.

про аргумент "проигрывают в длине" -- я молчу.

 

[untied]

Originally posted by Frol
про аргумент "проигрывают в длине" -- я молчу.

А чем это не аргумент?
Пришли к тому, что есть два варианта хранения даты в MySQL.
1. Хранить в BIGINT и преобразовывать ф-ей date();
2. Хранить в DATETIME и преобразовывать встроенными функциями MySQL.

Оба типа имеют длину 8 байт.
Ты, Frol, считаешь, что вариант номер 2 лучше. Вот и обоснуй, почему. А то всё какие-то голословные утвердения от тебя слышны: "да то!", "да не то!", "да я вообще молчу!".

А у меня есть два аргумента за вариант номер 1.
а) в этом случае запрос более короткий и удобочитаемый.
б) он отвечает (ну почти) стандарту SQL'92.

 

[Фанат]

интересно, зачем ему 8 байт...

 

[Screjet]

В MySQL действительно есть встроенные функции для преобразования меток времени, только sql-запрос от их использования проигрывает и в читаемости и в длине.

Это палка о двух концах.
..посмотрим что ты скажешь, когда придется создавать различные отчеты.
(за вчера, за неделю, по каждому месяцу.. и т.д. )

Если в БД есть тип, совпадающий с типом сущности, чего изобретать велосипед?

 

[untied]

Originally posted by Фанат
интересно, зачем ему 8 байт...

Фанат, спроси это на dev.mysql.com, зачем они заложили в DATETIME 8 байт.
Думаю, тебе ответят (если ответят), что это сделано про запас. Никто еще толком не знает, что будет после окончания эпохи Юникс (то ли объявят новую эпоху, то ли решат использовать 8 или 16 байт под хранение меток времени), а программы должны работать... Обратная совместимость там, переносимость скриптов и все такое...
(в том, что мои теперешние скрипты будут работать после окончания эпохи Юникс, я сильно сомневаюсь... а BIGINT я выбрал просто потому, что так...)

Screjet, согласен. Но под серьезные проекты с регулярными отчетами может лучше брать что-нибудь более серьезное, нежели MySQL?
Да и потом, про DATETIME ничего не сказано ни в SQL'92, ни в SQL'99. И про встроенные в MySQL функции преобразования времени тоже ничего не сказано. И если понадобится переходить с MySQL на что-нибудь более серьезное, появятся проблемы переносимости.
Про BIGINT в этих стандартах тоже ничего не сказано, но все-таки проблем меньше...

PS. Молчишь, Frol? Молчи, молчи...

 

[Фанат]

untied
меня поражает сочетание твоей тупости с наглостью.
У человека не хватает ума понять, что тип datetime НИКАКОГО ВООБЩЕ не имеет отношения к юниксовому таймстампу. и уж тем более, не имеет отношения к юниксовому таймстампу его размер.
у человека не хватает ума понять простой русский язык, оторым его спросили, зачем ему под юникс таймстамп 8 байт.
НО при этом у него хватает наглости воображать, будто кому-то понадобились его рассуждания о соображениях разработчиков мускуля.
У человека хватает ума только на то, чтобы промямлить нечленораздельное "просто потому".
НО при этом хватает наглости тявкать на человека, который тратит своё время на такое бесполезное занятие, как вбивание в этого буратины прописных истин.

 

[Frol]

untied
я промолчу.
ибо тебе бесполезно что-то говорить.

я тебе показал почему.
если до тебя не доходит -- не моя проблема.