Всем доброго времени суток!
Буквально месяц назад начала ознакомление с Android ОС и разработкой приложений под эту платформу. Как бывший администратор СУБД Oracle, меня сильно разочаровало то, что в SQLiteнет специализированного типа для хранения даты и времени. Задача заключалась в том, чтобы сохранять в базе время добавления элементов разрабатываемого приложения. Сёрфинг по сайтам и форумам навел на 2 возможные варианты:
— Закидывать в базу нужным образом отформатированное время в формате STRING
— Хранить время в LONG
Недостатки хранения времени в STRING:
— Неэффективность использования памяти. В связи с тем, что в SQLite нет формата LONG, то системное время System.currentTimeMillis() полученное в LONG, при занесении в базу будет преобразован в INTEGER. В 32-битных системах под INTEGER выделяется 4 байта. Строковое представление времени в human readable формате явно занимает в разы больше памяти чем 4 байта.
— Неэффективный расход времени при выполнении выборок из базы. Сравнение двух строк происходит, очевидно, дольше сравнения двух чисел.
С учетом этих пунктов было принято решение хранить время в INTEGER. Для отображения времени на странице деталей элемента время вытаскивалась из базы SQLite функцией strftime(format, timestring, modifier, modifier, ...) с unixepoch модификатором. Результат получался невообразимо бредовым. У каждого элемента время занесения в систему было '1970-01-01 00:00:00'. В этот момент вспоминаем, что время в UNIX это секунды с 1970 года. Именно! СЕКУНДЫ! Я в бд заносила число System.currentTimeMillis(), то есть количество миллисекунд. Это означало, что в бд нужно заносить полученное системное время деленное на 1000 или использовать strftime с параметром timestring/1000. Был выбран первый способ и на этом СЧАСТЬЕ НАСТУПИЛО!
Всем спасибо за внимание!
Буквально месяц назад начала ознакомление с Android ОС и разработкой приложений под эту платформу. Как бывший администратор СУБД Oracle, меня сильно разочаровало то, что в SQLiteнет специализированного типа для хранения даты и времени. Задача заключалась в том, чтобы сохранять в базе время добавления элементов разрабатываемого приложения. Сёрфинг по сайтам и форумам навел на 2 возможные варианты:
— Закидывать в базу нужным образом отформатированное время в формате STRING
— Хранить время в LONG
Недостатки хранения времени в STRING:
— Неэффективность использования памяти. В связи с тем, что в SQLite нет формата LONG, то системное время System.currentTimeMillis() полученное в LONG, при занесении в базу будет преобразован в INTEGER. В 32-битных системах под INTEGER выделяется 4 байта. Строковое представление времени в human readable формате явно занимает в разы больше памяти чем 4 байта.
— Неэффективный расход времени при выполнении выборок из базы. Сравнение двух строк происходит, очевидно, дольше сравнения двух чисел.
С учетом этих пунктов было принято решение хранить время в INTEGER. Для отображения времени на странице деталей элемента время вытаскивалась из базы SQLite функцией strftime(format, timestring, modifier, modifier, ...) с unixepoch модификатором. Результат получался невообразимо бредовым. У каждого элемента время занесения в систему было '1970-01-01 00:00:00'. В этот момент вспоминаем, что время в UNIX это секунды с 1970 года. Именно! СЕКУНДЫ! Я в бд заносила число System.currentTimeMillis(), то есть количество миллисекунд. Это означало, что в бд нужно заносить полученное системное время деленное на 1000 или использовать strftime с параметром timestring/1000. Был выбран первый способ и на этом СЧАСТЬЕ НАСТУПИЛО!
Всем спасибо за внимание!