- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
Сколько говна уже придумано было...:
$lasthour = date("Y-m-d H:i:s", mktime(date("H")-1, date("i"), date("s"), date("m"), date("d"), date("Y")));
$query = "
UPDATE user_sid
SET online = 0
WHERE date_action < '{$lasthour}'
";
$sql->query($query);
Вместо простого и понятного:
$query = "
UPDATE user_sid
SET online = 0
WHERE date_action < DATE_FORMAT( NOW( ) - INTERVAL 1 HOUR , '%Y-%m-%d %H:%i:%s' )
";
$sql->query($query);
Follow us!
$query = "
UPDATE user_sid
SET online = 0
WHERE date_action < NOW( ) - INTERVAL 1 HOUR";
$sql->query($query);
Да.
> только время БД
Я бы, наоборот, предпочёл время PHP. В БД оно только хранится, управляющая-то логика вся в PHP.
Где участвует время в логике проекта, если не трудно, 1 пример приведите пожалуйста.
Ну так вот, по уму следовало бы либо занести имя файла в базу с помощью NOW(), а потом сделать лишний селект, чтобы его вытащить и поименовать файл, либо поименовать файл time()'ом и потом уже занести его имя в базу. Выбор очевиден, имхо.
Если говно, это сразу видно. Поверьте мне.
>Не унижайте себя до этого.
отлично сказано
Вот как раз для фанатов Билана и Тимати приходится разъяснять. Но разве их голоса для нас авторитет?
на большом кол-во записей в БД - намного быстрее.
а в запросе DATE_FORMAT ни к чему
а DATE_FORMAT и NOW внутри WHERE ни к чему хорошему не приведут
mktime(date("H")-1, date("i"), date("s"), date("m"), date("d"), date("Y"))
Что, если первый вызов пришёлся на 21:59:59.999. Тогда первая date("H") - вернёт 21, а второй вызов date("i") - вернёт 00. Итого дата сформируется совсем неправильная.
Я просто указал на сложноотлаживаемую ошибку.
Подобные ошибки консистентности и написение non-threadsafe кода в мультипоточных системах - самые геморные для отладки. Потому я и привёл пример, обучающий момент, так сказать.