Последовательная обработка DateTimes в разных СУБД
Я планирую распределенную систему приложений, которая будет взаимодействовать с различными типами СУБД. Одно из требований - согласованная обработка DateTimes во всех типах СУБД. Все значения DateTime должны иметь точность до миллисекунды, включать информацию о часовом поясе и храниться в одном столбце.
Поскольку разные СУБД обрабатывают дату и время по-разному, я беспокоюсь, что не могу полагаться на их собственные типы столбцов в этом случае, и поэтому мне придется придумать другое решение. (Если я ошибаюсь, вы можете указать мне дорогу.)
Решение, каким бы оно ни было, в идеале должно обеспечивать простую сортировку и сравнение на уровне SQL. Другие аспекты, такие как удобочитаемость и возможность использования функций SQL datetime, не важны, поскольку все это будет обрабатываться службой шлюза.
Я пытаюсь сохранить свои значения DateTime в столбце типа unsigned largeint (8 байтов). Я не удостоверился, что все рассматриваемые СУБД (MSSQL, Oracle, DB2, PostgreSQL, MySQL, возможно, некоторые другие) действительно / имеют / такой тип, но на данный момент я просто предполагаю, что они есть.
Что касается формата хранения ... Например, 2009-01-01T12: 00: 00.999 + 01: 00 может храниться аналогично? 20090101120000999 ??, который занимает менее 8 байт.
Минимальное значение DateTime, которое я мог бы сохранить таким образом, было бы 0001-01-01T00: 00: 00.000 + xx: xx, а максимальное - 8000-12-31T23: 59: 59.999 + xx: xx, что дает мне пролета более чем достаточно.
Поскольку максимальное значение unsigned largeint равно 18446744073709551615, это оставляет мне следующие 3 цифры (отмеченные A и BB) для хранения информации о часовом поясе: AxxxxxxxxxxxxxxxxxBB.
Принимая во внимание максимальный годовой промежуток 0001..8000, A может быть 0 или 1, а BB может быть от 00 до 99.
А теперь вопросы:
Что вы думаете о предложенном мной решении? Есть ли в этом заслуги или это просто глупо?
Если лучшего способа не существует, как вы предлагаете наилучшим образом использовать три оставшиеся цифры для информации о часовом поясе?
Ответы 1
Я предлагаю вам хранить информацию о дате и времени в миллисекундах с 1970 года (стиль Java). Это стандартный способ хранения информации о дате и времени, кроме того, он более эффективен с точки зрения места, чем ваше предложение. Потому что в вашем предложении некоторые цифры "потрачены впустую", т.е. цифры месяца могут хранить только 00-12 (вместо 00-99) и так далее. Вы не указали, какой у вас язык разработки, но я уверен, что вы можете найти множество фрагментов кода, которые преобразуют дату в миллисекунды. Если вы разрабатываете в .NET, у них аналогичная концепция клещей. (вы также можете использовать эту информацию)
Что касается часового пояса, я бы добавил еще один столбец для хранения только индикации часового пояса.
Помните, что любой выбранный вами формат должен поддерживать согласованность между двумя датами, т.е. если D1> D2, то формат (D1)> формат (D2), таким образом вы можете запросить БД на предмет изменений с некоторой даты или запросить изменения между двумя датами.
Как сделать 6 байтов такими же, как 8 байтов. Что касается вашего вопроса, я не совсем понял, для чего нужна первая цифра? Потому что он определит результат сравнения двух дат.
Ну, я не знаю ни одного числового столбца, который занимал бы 6 байтов. Это либо 4 (int), либо 8 (largeint), ничего между ними. Так что, если что-то занимает 5 или 6 байт, вам все равно нужно использовать largeint. Что касается первой цифры: вы правильно подметили. Я думаю, это автоматически исключает это.
Num. миллисекунд с 1970 года означает использование 6 байтов для текущих значений DateTime, что по эффективности точно такое же, как и предложенные мной 8 байтов, независимо от потраченных впустую цифр. По поводу вашего последнего абзаца, касающегося согласованности и запросов ... Считаете ли вы, что предлагаемое мной решение их не покрывает? Спасибо