Дата против миллисекунд | для масштабируемости, сохранения, поиска и получения времени в Java + MySQL (или других БД)

Что наиболее полезно в Java и БД для DateTime? (Использование JodaTime в качестве даты)

(Объект DateTime (Java) + TIMESTAMP (DB)) VS (длиной в миллисекундах (Java) + BIGINT(DB)

для использования информации DateTime в веб-приложении Java, поддерживаемом базовой базой данных

Области, представляющие интерес

  • манипулирование, обработка и использование памяти в Java
  • экономия с использованием эффективного места для хранения в базе данных MySQL
  • простота переноса столбца BIGINT/TIMESTAMP в другие БД
  • простота поиска в БД для BIGINT/TIMESTAMP или между двумя BIGINT/TIMESTAMP

Например. Скажем, у меня было событие с началом и концом DateTime. Быстрее ли искать события по датам, используя BIGINT в БД, чем TIMESTAMPS

Я мог бы поменять базовую БД, поскольку возникают проблемы с масштабируемостью и поиском.

Будет ли сохранение DateTime как TIMESTAMP в базе данных MySQL приводить к проблемам при переносе на другую базу данных, например Oracle?

В настоящее время я использую Joda DateTime в java, а затем сохраняю миллисекунды этого значения.

При его извлечении я конвертирую миллисекунды обратно в объект DateTime и отображаю его.


java database datetime jodatime
person Daxon    schedule 24.09.2009    source источник

Ответы (3)


arrow_upward
1
arrow_downward

Тут действительно два вопроса. Во-первых, какую абстракцию следует использовать в Java для представления времени? Joda Time определенно лучше, чем java.util.Date. Если вам интересно, использовать ли просто длинное -- я полагаю, что вы не сможете обойтись без этого, если вам нужно выполнить какие-либо манипуляции с датами или сравнение. Итак, Джода Тайм.

И тогда, безусловно, лучше всего использовать TIMESTAMP для этого в MySQL, так как это будет почти идентично с точки зрения хранения, и MySQL будет правильно обрабатывать значение как дату, когда вы хотите использовать функции даты в столбце. Драйверы JDBC также поймут, что он должен быть сопоставлен с типом даты.

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

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

person Sean Owen    schedule 25.09.2009

arrow_upward
4
arrow_downward

Я всегда использую подход «миллисекунды с 1970 года». Таким образом, мне не нужно беспокоиться о том, к какому часовому поясу относится дата, потому что дата в базе данных всегда UTC.

person Bombe    schedule 24.09.2009
comment
Это две разные вещи, которые вы можете использовать для хранения даты и времени в формате UTC, чтобы вы могли игнорировать тимзоны с полями даты и времени. - person mmmmmm; 24.09.2009
comment
Я никогда не получал похвалы за его использование, но я также и всегда использую время эпохи 1970 года, и мой SQL и логика пережили много времени DST в системах планирования и бронирования. - person Jé Queue; 31.10.2009

arrow_upward
0
arrow_downward

Конечно, это зависит от того, что вы хотите делать с данными, но я бы рекомендовал использовать собственный тип БД для времени/даты (что бы это ни было) для хранения в БД. Это стандарт для баз данных, и большинство функций даты/времени в БД ожидают данные в этой форме.

Специальное примечание о MySQL:

Хотя вы можете использовать TIMESTAMP для значений даты/времени, имейте в виду, что TIMESTAMP не может записывать даты ранее, чем 1970-01-01. Таким образом, хотя это нормально для дат, близких к «сейчас» (таких как даты создания/изменения), это не подходит для возможных исторических дат, таких как дата рождения. Поэтому используйте TIMESTAMP только в том случае, если вы полностью уверены, что вам никогда не понадобятся исторические даты.

person sleske    schedule 24.09.2009
comment
Большинство баз данных также имеют более одного типа данных даты/времени, которые различаются по диапазону и точности, поэтому вы можете выбрать наиболее подходящий. - person David R Tribble; 24.09.2009