Как Вы храните диапазоны Даты, которые являются на самом деле метками времени

Закройте IntelliJ IDEA, затем удалите папку плагина из вашей файловой системы в $HOME/.IntelliJ2018.x/config/plugins.

7
задан Chris Noe 1 October 2008 в 19:53
поделиться

10 ответов

Вот то, как мы делаем это.

  1. Используйте метки времени.

  2. Используйте Полуоткрытые интервалы для сравнения: start <= now < end.

Проигнорируйте нытиков, которые настаивают, что МЕЖДУ так или иначе важно для успешного SQL.

С этим серию диапазонов даты действительно легко контролировать. Значение базы данных для 9/30 to 10/1 охватите один день (9/30). Запуск следующего интервала должен равняться концу предыдущего интервала. Это interval[n-1].end == interval[n].start правило удобно для аудита.

Когда Вы отображаетесь, если Вы хотите, можно отобразить отформатированный start и end- 1. Оказывается, можно обучить людей понимать, что "конец" является на самом деле первым днем, правило больше не верно. Так "9/30 к 10/1" означает "допустимый запуск 9/30, больше не действительный запуск 10/1".

7
ответ дан 6 December 2019 в 12:56
поделиться

Oracle имеет Тип данных timestamp. Это хранит год, месяц и день типа данных ДАТЫ, плюс час, минута, значения второй и доли секунды.

Вот поток на asktom.oracle.com об арифметике дат.

4
ответ дан 6 December 2019 в 12:56
поделиться

Я второй, что. Lott объяснил. У нас есть пакет продуктов, который делает широкое применение диапазонов времени даты, и это был один из наших изученных урокам для работы с диапазонами как этот. Между прочим, мы называем дату окончания эксклюзивной датой окончания, если это не часть диапазона еще (IOW, половина открытого интервала). Напротив, это - содержащая дата окончания, если это рассчитывает как часть диапазона, который только имеет смысл, если нет никакой части времени.

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

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

3
ответ дан 6 December 2019 в 12:56
поделиться

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

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

Например, ограничительная ПРОВЕРКА (MY_DATE=TRUNC (MY_DATE)) предотвращает значение со временем кроме 0:00:00, помещаемого в my_date столбец, и также позволяет Oracle выводить, что предикат, такой как MY_DATE = TO_DATE ('12.09.2008 15:00:00') никогда не будет верен, и следовательно никакие строки не будут возвращены из таблицы, потому что это может быть расширено до:

MY_DATE = TO_DATE('2008-09-12 15:00:00') AND
TO_DATE('2008-09-12 15:00:00') = TRUNC(TO_DATE('2008-09-12 15:00:00'))

Это автоматически ложно, конечно.

Хотя иногда заманчиво сохранить даты как числа такой как 20080915, это может вызвать проблемы оптимизации запросов. Например, сколько легальных значений там между 20,071,231 и 20,070,101? Как насчет между датами 31 декабря 2007 abnd 01 января 2008? Это также позволяет недопустимым значениям вводиться, такой как 20070100.

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

select ...
from   ...
where  my_date Between date '2008-01-01' and date '2008-01-05'

Когда существует компонент времени, можно выполнить одно из следующих действий:

select ...
from   ...
where  my_date >= date '2008-01-01' and
       my_date  < date '2008-01-06'

или

select ...
from   ...
where  my_date Between date '2008-01-01'
                   and date '2008-01-05'-(1/24/60/60)

Отметьте использование (1/24/60/60) вместо магического числа. Довольно распространено в Oracle выполнить арифметику дат путем добавления определенных частей дня... 3/24 в течение трех часов, 27/24/60 в течение 27 минут. Математика Oracle этого типа точна и не переносит погрешностей округления, таким образом:

select 27/24/60 from dual;

... дает 0.01875, не 0.01874999999999 или что бы то ни было.

2
ответ дан 6 December 2019 в 12:56
поделиться

Я еще не вижу типы данных Интервала, отправленные.

Oracle также имеет типы данных для Вашего точного сценария. Существует ГОД ИНТЕРВАЛА К МЕСЯЦУ и ДНЮ ИНТЕРВАЛА К ВТОРЫМ типам данных в Oracle также.

От 10gR2 документы.

ГОД ИНТЕРВАЛА К МЕСЯЦУ хранит промежуток времени с помощью полей даты и времени ГОДА и МЕСЯЦА. Этот тип данных полезен для представления различия между двумя значениями даты и времени, когда только значения года и месяца являются значительными.

ГОД ИНТЕРВАЛА [(year_precision)] К МЕСЯЦУ

где year_precision является количеством цифр в поле даты и времени ГОДА. Значение по умолчанию year_precision равняется 2.

ДЕНЬ ИНТЕРВАЛА К ВТОРОМУ типу данных

ДЕНЬ ИНТЕРВАЛА К ВТОРЫМ хранилищам промежуток времени с точки зрения дней, часов, минут и секунд. Этот тип данных полезен для представления точного различия между двумя значениями даты и времени.

Укажите этот тип данных следующим образом:

ДЕНЬ ИНТЕРВАЛА [(day_precision)] К ВТОРОМУ [(fractional_seconds_precision)]

где

day_precision является количеством цифр в ДНЕВНОМ поле даты и времени. Принятые значения от 0 до 9. Значение по умолчанию равняется 2.

fractional_seconds_precision является количеством цифр в дробной части ВТОРОГО поля даты и времени. Принятые значения от 0 до 9. Значение по умолчанию равняется 6.

У Вас есть большая гибкость при определении значений интервала как литералов. См. "Литералы Интервала" для получения дальнейшей информации на указывают значения интервала как литералы. Также см. "Дату и время и Примеры Интервала" для примера с помощью интервалов.

1
ответ дан 6 December 2019 в 12:56
поделиться

На основе моих событий существует четыре основных способа сделать это:

1) Преобразуйте дату в целое число эпохи (секунды начиная с 1-го Jan 1970) и сохраните ее в базе данных как целое число.

2) Преобразуйте дату в целое число YYYYMMDDHHMMSS и сохраните ее в базе данных как целое число.

3) Сохраните его как дату

4) Сохраните его как строку

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

0
ответ дан 6 December 2019 в 12:56
поделиться

Основанный на Вашем первом предложении, Вы натыкаетесь на одну из скрытых "функций" (т.е. ошибки) Java: java.util.Date должно было быть неизменным, но это не. (Java 7 обещает зафиксировать это с новой датой/временем API.) Почти каждое корпоративное приложение рассчитывает на различные временные шаблоны, и в какой-то момент необходимо будет сделать арифметику в дату и время.

Идеально, Вы могли использовать время Joda, которое используется Google Calendar. Если Вы не можете сделать этого, я предполагаю API, который состоит из обертки вокруг java.util.Date с вычислительными методами, подобными Grails/направляющим, и диапазона Вашей обертки (т.е. упорядоченная пара, указывающая на запуск и конец периода времени), будет достаточно.

На моем текущем проекте (приложение хронометрирования HR) мы пытаемся нормализовать все наши Даты к тому же часовому поясу и для Oracle и для Java. К счастью, наши требования локализации легки (=, 1 часовой пояс достаточно). Когда для постоянного объекта не нужна более прекрасная точность, чем день, мы используем метку времени по состоянию на полночь. Я пошел бы далее и настоял бы на выбрасывании дополнительных миллисекунд к самой грубой гранулярности, которую постоянный объект может терпеть (это сделает Вашу обработку более простой).

0
ответ дан 6 December 2019 в 12:56
поделиться

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

В случаях, где день, неделя, месяц, и т.д. манипуляции необходимы в запросах базы данных, и когда производительность запросов является главной, метки времени (нормализованный к более высокой гранулярности, чем миллисекунды) могут быть связаны с аварийной таблицей даты, которая имеет столбцы в течение дня, неделя, месяц, и т.д. оценивает так, чтобы дорогостоящие функции даты/времени не использовались в запросах.

0
ответ дан 6 December 2019 в 12:56
поделиться

Alan прав - время Joda прекрасно. java.util. Дата и Календарь являются просто позором.

Если Вы нуждаетесь в использовании меток времени тип даты оракула со временем, называете столбец с некоторым суффиксом как _tmst. Когда Вы считываете данные в Java, получают его в joda время объект DateTime. для проверки часовой пояс является правильным, полагают, что существуют определенные типы данных в оракуле, который снабдит метки времени часовым поясом. Или можно создать другой столбец в таблице для хранения идентификатора часового пояса. Значения для идентификатора часового пояса должны быть стандартным идентификатором полного имени для Часовых поясов, см. http://java.sun.com/j2se/1.4.2/docs/api/java/util/TimeZone.html#getTimeZone%28java.lang.String%29. Если Вы используете другой столбец для TZ dta затем при чтении данных в Java, используют объект DateTime, но устанавливают часовой пояс на объекте DateTime использование .withZoneRetainFields для установки часового пояса.

Если Вам только нужны данные даты (никакая метка времени) затем используют тип даты в базе данных без времени. снова назовите его хорошо. в этом случае используют объект DateMidnight от jodatime.

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

0
ответ дан 6 December 2019 в 12:56
поделиться

Я храню все даты в миллисекундах. Я не использую поля меток времени/даты и времени вообще.

Так, я должен управлять им как longs. Это означает, что я не использую 'прежде', 'после', 'теперь' ключевые слова в моих запросах SQL.

-1
ответ дан 6 December 2019 в 12:56
поделиться
Другие вопросы по тегам:

Похожие вопросы: