|
| |
|
|
| |
для: Eugene77
(12.02.2008 в 16:53)
| | | потому что в этом случае INT использовать не получится..
хотя конечно можно извратиться, сохранять дату как число типа 20080101000000.. но с unix_timestamp в дальнейшем и работать удобнее будет | |
| |
|
|
| |
|
|
| |
для: cheops
(12.02.2008 в 11:58)
| | | >Всё таки наверное лучше в unix timestamp, выбрав для этого поле INT
Почему не timestamp? | |
| |
|
|
| |
|
|
| |
для: cheops
(12.02.2008 в 11:58)
| | | Фактически даты получаются разными. Насколько я понимаю, тогда и в индексе будет столько же значений, сколько и в оригинальной таблице? Насколько оправдан индекс в таком случае? И еще вопрос: Хочу приобрести Вашу книжку - самоучитель по MySQL 5. Есть ли в ней информация об особенностях таблиц разных типов, их слабых и сильных сторонах? И как насчет "правил" оптимизации запросов? | |
| |
|
|
| |
|
|
| |
для: Woland
(12.02.2008 в 06:33)
| | | Всё таки наверное лучше в unix timestamp, выбрав для этого поле INT - поле datetime очень плохо индексируется и работа с ним протекает медленее. | |
| |
|
|
| |
|
|
| | Подскажите, в каком формате лучше хранить дату и время - в поле datetime или как целое число секунд (unix timestamp)? Приоритетные операции - выборка данных за определенный промежуток времени, но данных очень много - до 10 миллионов строк, критический фактор - быстродействие. Кроме того, даты в таблице не убывают. Можно ли это условие использовать для оптимизации производительности запроса? | |
| |
|
|
|
