ФорумРазработкаУстановка и администрирование ПОСерверы баз данных → Конвертация временной метки: оптимальные приемы.

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

  • Rotten

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

    Spritz Янв. 17, 2011, 2:59 д.п.

    Кто как конвертирует unix timestamp из базы в базу?

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

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

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

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

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

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

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

    Spritz Янв. 17, 2011, 3:03 д.п., спустя 3 минуты 51 секунду

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

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

    Spritz Янв. 17, 2011, 4:01 д.п., спустя 58 минут 41 секунду

    SELECT FROM_UNIXTIME(myunixtime) AS 'data' FROM table
  • adw0rd

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

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

    1. храню в TIMESTAMP
    2. SELECT timestamp_field
    3. SELECT UNIX_TIMESTAMP(timestamp_field)
    https://smappi.org/ - платформа по созданию API на все случаи жизни
  • artoodetoo

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

    Spritz Янв. 17, 2011, 7:38 п.п., спустя 11 часов 59 минут 5 секунд


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

    +1
    не вижу профита в масиквельном datetime
    ιιlllιlllι унц-унц
  • Rotten

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

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

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

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

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

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

    Spritz Янв. 18, 2011, 4:11 д.п., спустя 27 минут 8 секунд

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

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

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

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

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

    Spritz Янв. 18, 2011, 5:41 д.п., спустя 13 минут 50 секунд

    artoodetoo, не знаю что такое pma, но то что через скл-вьювер, то да…
    Спустя 215 сек.
    Faster, а там что TIMESTAMP, DATE, DATETIME - не ошыбешся… ведь оператор перегруженный…
    Да и потом, наоборот мне кажется проще запросить чтото по типу
    time < INTERVAL 3 DAYS
    ибо сразу понимаешь а не переумножаешь в уме…
  • artoodetoo

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

    Spritz Янв. 18, 2011, 6:40 д.п., спустя 58 минут 49 секунд

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

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

    Spritz Янв. 18, 2011, 6:57 д.п., спустя 17 минут 21 секунду

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


    Оно и видно…
  • Faster

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

    Spritz Янв. 18, 2011, 8:46 д.п., спустя 1 час 48 минут 30 секунд

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

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

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

    Spritz Дек. 16, 2011, 6:54 п.п., спустя 332 дня 10 часов 8 минут

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

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

    Spritz Фев. 19, 2013, 5:45 д.п., спустя 430 дней 10 часов 50 минут

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

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

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

    Spritz Фев. 19, 2013, 5:56 д.п., спустя 10 минут 49 секунд

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

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

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