time() vc date(now) ?

  • Автор темы Wingely Dog
  • Дата начала

Wingely Dog

Guest
time() vc date(now) ?

расскажите про преимущество хранения временных отметок в формате sql date по сравнению с обычным int от time() ?
 

Demiurg

Guest
в int надо хранить целые числа а для дат и времени во многих субд есть спецальные типы.
 

Wingely Dog

Guest
time() = целое число 8)

и конешна же есть специальные типы. я потому и спрашиваю в чем может быть преимущество использования оных? мне почему-то видны только неудобства. т.к. int я всегда могу очень удобно отформатировать в представлении с помощью date(). а если я храню время в специальном типе внутри бд, то дата_екстрактор модели должен будет отвечать за извлечение времени в соответствующем формате.

кстати говоря, int надо полагать 4 байта, а сколько байт занимает специальный тип даты в бд?
 

Demiurg

Guest
Для форматирования в субд опять же есть функции. Кроме того, когда тебе нужна именно дата зачем хранить еще и время ? И еще сравни диапазон типа date и unix timpstamp.

>кстати говоря, int надо полагать 4 байта, а сколько байт занимает специальный тип даты в бд?
на спичках экономим ?
 

SiMM

Новичок
Думаю, для своей БД он подобное найдёт сам ;) - рассматривайте это как руководство к действию, aka поиску нужных функций.
 

Wingely Dog

Guest
2Demiurg
сегодня тебе время не нужно, завтра заказчик захочет. в случае если использовался таймстамп поменяется строчка в конфиге ответственная за формат даты, в случае даты во внтуреннем формате sql предется переделывать sql запрос.

2 SiMM
я знаю вас из дас DATE_FORMAT я пытаюсь осознать необходимость оного 8)

2all
ват абоут моего замечания разделения обязанностей модели и отображения?
 

Фанат

oncle terrible
Команда форума
дату нетрудно отформатировать в скрипте, собственной функцией.
тем более, тчо для русского языка это все равно понадобится.

впрочем, уговаривать здесь тебя никто не собирается.
 

Wingely Dog

Guest
да я как бы и не напрашиваюсь на уговоры.

вопрос то прозаичный. на оно нада и какие от этого радости?
 

Demiurg

Guest
Wingely Dog
а послезавтра заказчик захочет время с точностью до милисекунды. Что тогда ?
 

Фанат

oncle terrible
Команда форума
Demiurg
это не тот аргумент.
я думаю, не стоит его уговаривать. если он не понял сразу, то дальше бесполезно.
 

Wingely Dog

Guest
2Demiurg
да, проблема 8/

2Фанат.
я думаю, не стоит его уговаривать
сдается мне это вас нада будет скоро уговаривать, что никого уговоривать не нада 8)
если он не понял сразу, то дальше бесполезно.
сразу? помоему от вас не было ни одно аргумента за ( кроме тыка носом в то что оно есть )
 

SiMM

Новичок
Wingely Dog, представь себе ситуацию, что тебя интересует некоторая выборка за декабрь любого года. С таймштампом тебе придётся применять что-то типа FROM_UNIXTIME + MONTH, с DATE этого делать не придётся. Кроме того, диапазон допустимых значений дат, обеспечиваемый типом поля DATE, на данный момент гораздо больше, чем у таймштампа. Это становится заметным, если пытаться датировать прошлое, например, 1 января 1900 года ;)
 

Wingely Dog

Guest
да, со старыми датами явный облом, согласен, аргумент.

насчет красивости написания условия выборки вопрос мутный. Особенно если учесть что SQL запросы часто генерируются, а не пишутся руками.
 

SiMM

Новичок
Wingely Dog, дело не в красивости - а в лишних операциях и преобразованиях - FROM_UNIXTIME + MONTH в любом случае будет медленнее MONTH
 

Wingely Dog

Guest
ну длинна MONTH'a у них тоже не во вселенсоком разуме хранится, все равно оно внутри в нечто универсальное переводится ( может в тот же int ).
как бы то ни было это тоже экономство на спичках 8)
 
Сверху