Конвертация временной метки: оптимальные приемы.

Страницы: ← Следующая страница →

Rotten

Сообщения: 2243 Репутация: N Группа: Адекваты
17 января 2011 г. 13:59
Кто как конвертирует unix timestamp из базы в базу?

Мне кажеться, что неплохо в mysql хранить колонку в формате DATETIME, а в пхп конвертировать по типу
date("U",strtotime($row["time"]))

если нужна метка.

Ну а INSERT делать
date("Y-m-d H:i:s",$timestamp)

Соответственно…

Никто случайно из вас напрямую не умудрялся хранить численное значение метки в бд, и не конвертируя, напрямую используя ее в интерпретаторе?
Я нигде такого не встречал лично. Нтересно, почему…

Вашы - мнения…
Faster

Сообщения: 1159 Репутация: N Группа: Кто попало

17 января 2011 г. 14:03, спустя 3 минуты 51 секунду

я всегда юзаю таймстамп без поля DATETIME
удобнее
fgets

Сообщения: 1099 Репутация: N Группа: Кто попало
17 января 2011 г. 15:01, спустя 58 минут 41 секунду
SELECT FROM_UNIXTIME(myunixtime) AS 'data' FROM table
adw0rd

Сообщения: 22959 Репутация: N Группа: в ухо

17 января 2011 г. 18:38, спустя 3 часа 37 минут 4 секунды

1. храню в TIMESTAMP
2. SELECT timestamp_field
3. SELECT UNIX_TIMESTAMP(timestamp_field)

https://smappi.org/ - платформа по созданию API на все случаи жизни
artoodetoo

Сообщения: 5147 Репутация: N Группа: в ухо

18 января 2011 г. 6:38, спустя 11 часов 59 минут 5 секунд

я всегда юзаю таймстамп без поля DATETIME
удобнее

+1
не вижу профита в масиквельном datetime

ιιlllιlllι унц-унц
Rotten

Сообщения: 2243 Репутация: N Группа: Адекваты

18 января 2011 г. 14:44, спустя 8 часов 6 минут 22 секунды

Профит на самом деле есть.
например - в нашем проекте, когда чуть ли не каждый день приходится просматривать записи за тот или иной период с точностью до секунды.
Их просматривают тестеры, разработчики, ПМ…

Это не сайт, где пользователи чтото оставляют - а грубо говоря удаленный девайс, который генерирует данные на джава-мидлете данные, который(джава-мидлет) в свою очередь через СОАП постит в mysql.
Может и можно бы было создать какуюто отдельную а-ля админ-строаничку для удобочитаемости, но в проекте нету места пока для этого т.к. данные нужны лишь для разработчиков а не пользователей..

А для пользователей есть одтельный сайт, где они могут просматривать данные свои. Вот поттому и парсается значение DATETIME.
artoodetoo

Сообщения: 5147 Репутация: N Группа: в ухо

18 января 2011 г. 15:11, спустя 27 минут 8 секунд

твои тестеры их прямо в PMA просматривают? или таки в нормальной проблеммно-ориентированной среде?

ιιlllιlllι унц-унц
Faster

Сообщения: 1159 Репутация: N Группа: Кто попало

18 января 2011 г. 16:27, спустя 1 час 16 минут 18 секунд

Rotten,
сомнительное удобство
мне к примеру удобнее выборки делать такие timestamp (BD) < (60*60*24*3)
Rotten

Сообщения: 2243 Репутация: N Группа: Адекваты
18 января 2011 г. 16:41, спустя 13 минут 50 секунд
artoodetoo, не знаю что такое pma, но то что через скл-вьювер, то да…
Спустя 215 сек.
Faster, а там что TIMESTAMP, DATE, DATETIME - не ошыбешся… ведь оператор перегруженный…
Да и потом, наоборот мне кажется проще запросить чтото по типу
time < INTERVAL 3 DAYS
ибо сразу понимаешь а не переумножаешь в уме…
artoodetoo

Сообщения: 5147 Репутация: N Группа: в ухо

18 января 2011 г. 17:40, спустя 58 минут 49 секунд

Rotten, ебануться! больше нечего добавить.

ιιlllιlllι унц-унц
Rotten

Сообщения: 2243 Репутация: N Группа: Адекваты

18 января 2011 г. 17:57, спустя 17 минут 21 секунду

ебануться! больше нечего добавить.
=
с особым цинизмом

Оно и видно…
Faster

Сообщения: 1159 Репутация: N Группа: Кто попало

18 января 2011 г. 19:46, спустя 1 час 48 минут 30 секунд

artoodetoo,
+1
"опыт сын ошибок трупный …"

единственное мей би DATETIME индекс на больших выборках быстрее чем INT(10) - но не проверял, хз
PandoraBox2007

Сообщения: 21 Репутация: N Группа: Адекваты

17 декабря 2011 г. 6:54, спустя 332 дня 10 часов 8 минут

int(11) лучше быстрее, эфективнее
Спустя 192 сек.
DATETIME все равно при сохранении на диск производит перекодирование
master

Сообщения: 3244 Репутация: N Группа: Джедаи

19 февраля 2013 г. 17:45, спустя 430 дней 10 часов 50 минут

updated, created - хранить в TIMESTAMP
сохраняются и читаются как строки, хранятся как INT (4 байта)

все остальные вручную вводимые поля - как DATE/DATETIME, конвертировать в int не нужно
потому что хуй знает какую там дату запишут, может 1960й год,
а блядь, нет ничего хуже чем проебать данные
ну и при ковырянии в кишках БД удобно видеть дату в нативном виде, а не 1361281513

не всё полезно, что в swap полезло
master

Сообщения: 3244 Репутация: N Группа: Джедаи

19 февраля 2013 г. 17:56, спустя 10 минут 49 секунд

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

и да, думаю, не надо напоминать, что дату/время нужно хранить только в UTC, а при отображении пользователю конвертировать в его временную зону. да, для этого делается перевод через strtotime и обратно

не всё полезно, что в swap полезло

Страницы: ← Следующая страница →

Пожалуйста, авторизуйтесь, чтобы написать комментарий!

Конвертация временной метки: оптимальные приемы.

Войти