|
|
|
| В таблице имеются поля start и end с типами datetime.
Как правильно отсортировать запрос по количеству секунд между start и end, начиная от меньшего и заканчивая большим?
SELECT * FROM table ORDER BY ........ LIMIT 0,10
|
| |
|
|
|
|
|
|
|
для: Freddie_X
(26.02.2009 в 20:47)
| |
... ORDER BY `end` - `start` ASC ...
|
| |
|
|
|
|
|
|
|
для: BinLaden
(26.02.2009 в 20:58)
| | Так, вроде работает, но некорректно...
Идут по нарастающей, а результат, который должен стоять на 5-ом месте в запросе, стоит на последнем месте...
С чего бы это? о_О | |
|
|
|
|
|
|
|
для: Freddie_X
(26.02.2009 в 21:31)
| | Корректное сравнение будет
ORDER BY UNIX_TIMESTAMP(end) - UNIX_TIMESTAMP(start)
|
Или даже
ORDER BY TO_DAYS(end) - TO_DAYS(start) , UNIX_TIMESTAMP(end) - UNIX_TIMESTAMP(start)
|
| |
|
|
|
|
|
|
|
для: Trianon
(26.02.2009 в 21:40)
| | Спасибо! Первый вариант работает! :) | |
|
|
|
|
|
|
|
для: Freddie_X
(26.02.2009 в 21:31)
| | > С чего бы это
Корректнее
... ORDER BY DATEDIFF(`end`, `start`) ...
Хотя, наверное, через UNIX_TIMESTAMP'ы быстрее будет -- поля типа DATETIME в базе хранятся вроде бы в UNIX TIMESTAMP, и оптимизатор MySQL скорее всего это учитывает. | |
|
|
|
|
|
|
|
для: BinLaden
(26.02.2009 в 21:55)
| | Толя DATETIME хранятся не в timestamp .
The storage requirements shown in the table arise from the way that MySQL represents temporal values:
DATE: A three-byte integer packed as DD + MM * 32 + YYYY * 16 * 32
DATETIME: Eight bytes:
A four-byte integer packed as YYYY * 10000 + MM * 100 + DD
A four-byte integer packed as HH * 10000 + MM * 100 + SS
TIMESTAMP: A four-byte integer representing seconds UTC since the epoch ('1970-01-01 00:00:00' UTC)
|
Собственно именно поэтому end-start вычислялся некорректно.
Был бы он линеен - проблем бы не возникло. | |
|
|
|
|
|
|
|
для: Trianon
(26.02.2009 в 22:07)
| | Точно, я с TIMESTAMP спутал. | |
|
|
|