Модераторы: skyboy, MoLeX, Aliance, ksnk
  

Поиск:

Ответ в темуСоздание новой темы Создание опроса
> сравнение datetime 
V
    Опции темы
Loginanton
Дата 24.7.2009, 16:32 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Шустрый
*


Профиль
Группа: Участник
Сообщений: 114
Регистрация: 8.11.2007

Репутация: нет
Всего: нет



всем доброго время суток. такой вопрос: как из бд удалить все строки, дата создания которых отличается от текущей больше чем на 24 часа. дата создания - отдельная ячейка типа datetime, текущую дату получаю с помощью date('Y-m-d H:i:s'). заранее благодарен за помощь
PM   Вверх
skyboy
Дата 24.7.2009, 17:21 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


неОпытный
****


Профиль
Группа: Модератор
Сообщений: 9820
Регистрация: 18.5.2006
Где: Днепропетровск

Репутация: 14
Всего: 260



для mysql, например, datedif
для чего-то другого - что-то другое.
PM MAIL   Вверх
Mal Hack
Дата 24.7.2009, 17:41 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Мудрый...
****


Профиль
Группа: Участник Клуба
Сообщений: 9926
Регистрация: 15.2.2004

Репутация: 11
Всего: 261



Вообще, дату лучше в числах хранить. Unix Time так называемый. Ну или в другой форме. ТОгда все просто становится, ибо числа сравнивать намного проще.
PM ICQ   Вверх
Ипатьев
Дата 26.7.2009, 13:19 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2232
Регистрация: 5.7.2009

Репутация: 3
Всего: 37



Mal Hack, учитывая, что в большинстве баз данных есть встроенные функции для работы с полями типа "дата" (причем не ограниченными узким промежутком в 70 лет), то совет хранить время в секундах получится не очень полезным. Для такой простой задачи, как у автора, формат может быть любой. А если, скажем, надо работать с днями рождения, то unixtime задаст нам серьезную головоломку.

Цитата(Loginanton @  24.7.2009,  16:32 Найти цитируемый пост)
екущую дату получаю с помощью date('Y-m-d H:i:s')

Loginanton, в это трудно поверить, но в документации к функции date есть пример, как получить дату, которая отличается текущей на 24 часа
PM MAIL   Вверх
Mal Hack
Дата 26.7.2009, 14:01 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Мудрый...
****


Профиль
Группа: Участник Клуба
Сообщений: 9926
Регистрация: 15.2.2004

Репутация: 11
Всего: 261



Цитата(Ипатьев @  26.7.2009,  14:19 Найти цитируемый пост)
Mal Hack, учитывая, что в большинстве баз данных есть встроенные функции для работы с полями типа "дата" (причем не ограниченными узким промежутком в 70 лет), то совет хранить время в секундах получится не очень полезным. 

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


Цитата(Ипатьев @  26.7.2009,  14:19 Найти цитируемый пост)
Для такой простой задачи, как у автора,

Для простой задачи и надо использовать самые простые методы.

Цитата(Ипатьев @  26.7.2009,  14:19 Найти цитируемый пост)
А если, скажем, надо работать с днями рождения, то unixtime задаст нам серьезную головоломку.

А это уже другая задача.
PM ICQ   Вверх
Ипатьев
Дата 26.7.2009, 14:07 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2232
Регистрация: 5.7.2009

Репутация: 3
Всего: 37



Цитата(Mal Hack @  26.7.2009,  14:01 Найти цитируемый пост)
что будет быстрее

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

Цитата(Mal Hack @  26.7.2009,  14:01 Найти цитируемый пост)
А это уже другая задача. 

Мне кажется слишком расточительным держать два разных поля для одих и тех же данных. 
PM MAIL   Вверх
Mal Hack
Дата 26.7.2009, 14:22 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Мудрый...
****


Профиль
Группа: Участник Клуба
Сообщений: 9926
Регистрация: 15.2.2004

Репутация: 11
Всего: 261



Цитата(Ипатьев @  26.7.2009,  15:07 Найти цитируемый пост)
Мне кажется слишком расточительным держать два разных поля для одих и тех же данных.  

Где вы увидели у автора дополнительное поле?????


Цитата(Ипатьев @  26.7.2009,  15:07 Найти цитируемый пост)
Я думаю, одинаково.

Неправильно. Никогда вызов функции не будет быстрее или сравним по скорости со сравнением чисел. В Условии...
ДАже если вы будете в условии писать сравнение типов datatime, то это все равно будет медленнее, ибо мискул будет последовательно сравнивать значения байтов, относящихся к конкретного смысловому значению (год, месяц) и т.п. Т.е. вы будете иметь в 3 раза больше операций сравнения, плюс еще во внутренней функции (скорее всего), которую сами явно вызывать не будете.

PM ICQ   Вверх
Ипатьев
Дата 26.7.2009, 15:02 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Эксперт
****


Профиль
Группа: Завсегдатай
Сообщений: 2232
Регистрация: 5.7.2009

Репутация: 3
Всего: 37



Цитата(Mal Hack @  26.7.2009,  14:22 Найти цитируемый пост)
будет последовательно сравнивать значения байтов, относящихся к конкретного смысловому значению (год, месяц) 

Мне так не кажется. То есть,  я, во-первых, не вижу смысла сравнивать по-очереди, когда можно сравнить разом. А во-вторых, мне все это кажется экономией на спичках. К тому же, насколько я понимаю, mysql физически хранит datetime в виде числа, то есть, спорить и вовсе не о чем. 

Учитывая ограничения unixtime, я бы не стал рекомендовать такой вариант хранения даты, как более предпочтительный. Наоборот, я бы рекомендовал по умолчанию выбирать из встроенных типов данных, а время в секундах - в специфических случаях, только при наличии веских причин.
PM MAIL   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | PHP: Базы Данных | Следующая тема »


 




[ Время генерации скрипта: 0.0922 ]   [ Использовано запросов: 22 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.