Как сохранить datetime в SQLite

Это очень похоже на еще вопрос это было закрыто как не настоящий вопрос. Я попытался отредактировать его, чтобы сделать его действительным для повторного открытия, но мне сказали, что лучше задать новый вопрос.

Я разрабатываю на android и должен хранить значения datetime в базе данных sqlite для отслеживания повторяющихся событий, которые будут генерировать уведомления. Мне также нужно будет иметь возможность запрашивать базу данных на основе временных диапазонов.

на базы данных SQLite документация утверждает, что он не поддерживает определенные типы дат, но что даты могут быть представлены с помощью текстовых, реальных или целочисленных типов:

текст в виде строк ISO8601 ("гггг-ММ-ДД чч: мм: СС.СНО.)"

целое число как время Unix, количество секунд с 1970-01-01 00: 00:00 UTC.

преимущества каждого из них изначально кажутся:

  • текст полезен для удобочитаемости в базе данных с возможностью отображения непосредственно позже (преобразование не требуется), но дорого, если расчеты должны быть выполнены на них. Вводит возможную ошибку из часовых поясов.
  • REAL полезно для дат до 1970 года, хорошо для расчетов или сравнения дат. Не время суток, а только дни.
  • полезное целое число для вычислений или сравнения datetime очень хорошая совместимость, так как это широко поддерживаемый стандарт.

Это звучит правильно? Будет ли использование целого числа для datetimes делать диапазоны времени запросов заметно быстрее, чем при использовании текста? Что еще я не учел?

учитывая мой вариант использования, какое из этих решений было бы лучшим?

6
android android-sqlite database-performance datetime sqlite

4 ответов

текст полезен для чтения в базе данных с возможностью отображения непосредственно позже (преобразование не требуется)

формат ISO обычно не используется для отображения; вы также должны преобразовать это. (Этот формат более полезен для отладки.)

дорого, если расчеты должны быть выполнены на них

с базами данных, узким местом обычно является I/О. Я сомневаюсь, что вы видите запрос где фактический формат значений дат будет иметь заметное значение.

вводит возможную ошибку из часовых поясов.

в текстовом формате нет спецификатора часового пояса, но нет и других форматов. Если вы говорите, что все ваши значения БД находятся в UTC, нет никакой разницы.

REAL полезно для дат до 1970

все форматы поддерживают все годы между 0 и 9999. (Целые числа могут быть отрицательный.)

не представляет время суток, только дни.

время суток представлено в виде дробного значения.

целое число ... очень хорошая совместимость, так как это широко поддерживаемый стандарт.

но Java использует миллисекунды, а не секунды.

что-нибудь еще, что я не рассматривал?

формат вывода по умолчанию для большинства встроенный дата функции текст.

учитывая мой вариант использования, какое из этих решений было бы лучшим?

Я бы сказал текст, но я не думаю, что будет большая разница.

4

ответы здесь будут в первую очередь мнением, но на вашем месте я бы использовал целочисленный тип и сохранил метку времени unix. Он кажется менее зависимым от преобразования/синтаксического анализа формата и является наиболее универсально поддерживаемым стандартом.

1

не представляет время суток, только дни.

вот что такое дробная часть REAL для.

будет ли использование целого числа для datetimes делать диапазоны времени запросов заметно быстрее, чем при использовании текста?

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

что-нибудь еще, о чем я не подумал?

Я понятия не имею, рассматривали ли вы Влияние гамма-лучей на ноготки человека на Луне, но здесь это не важно. :-)

учитывая мой вариант использования, какое из этих решений было бы лучшим?

INTEGER, ИМХО.

0

храните время даты UTC как восьмибайтовое 64-битное целое число в SQLite. Millis sence 1970.

long time= System.currentTimeMillis();

с индексированной базой данных у вас будет отличный ответ для порядка 10k строк по порядку и между данными чтения datetime.

оставьте манипуляции часового пояса слою представления, потому что база данных со всеми временами UTC будет работать во всем мире.

Не храните даты как текст, который настолько древний и не имеет места в современном приложении.

Я бы избегайте хранения только даты, потому что современные приложения учитывают, когда произошло событие. Вы можете хранить datetimes с 8 байтами. Но если вы должны, вы можете просто поместить дату iso в целое число 1999-12-31 как 19991231 и сохранить 4-байтовое целое число в sqllite.

0