Согласованная обработка DateTimes в разных RDBMS - PullRequest
Новая
       9

Согласованная обработка DateTimes в разных RDBMS

2 голосов
/ 09 января 2009

Я планирую распределенную систему приложений, которая будет взаимодействовать с различными типами СУБД. Одним из требований является согласованная обработка DateTime для всех типов РСУБД. Все значения DateTime должны быть с точностью до миллисекунды, включать информацию о TimeZone и храниться в одном столбце.

Поскольку разные СУБД обрабатывают даты и время по-разному, я беспокоюсь, что в этом случае я не могу полагаться на их собственные типы столбцов, и поэтому мне придется придумать другое решение. (Если я ошибаюсь, вы можете указать мне путь.)

Решение, каким бы оно ни было, в идеале должно обеспечивать легкую сортировку и сравнение на уровне SQL. Другие аспекты, такие как удобочитаемость и возможность использования функций даты и времени SQL, не важны, поскольку все это будет обрабатываться службой шлюза.

Я играю с идеей сохранения значений 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.

А теперь вопросы:

  • Что вы думаете о моем предложенном решении? У этого есть заслуга или это просто глупо?

  • Если лучшего способа не существует, как вы предлагаете использовать три оставшиеся цифры для лучшей информации о TimeZone?

Большое спасибо за вашу помощь заранее!

1 Ответ

1 голос
/ 09 января 2009

Я бы предложил вам хранить информацию о дате и времени в миллисекундах с 1970 года (стиль Java). Это стандартный способ хранения информации о времени и дате, кроме того, он более эффективен с точки зрения пространства, чем ваше предложение. Потому что по вашему предложению некоторые цифры «пропадают», то есть цифры месяца могут хранить только 00-12 (вместо 00-99) и так далее. Вы не указали, какой у вас язык разработки, но я уверен, что вы можете найти много фрагментов кода, которые преобразуют дату в миллисекунды. Если вы разрабатываете в .NET, у них есть похожая концепция тиков. (вы также можете использовать эту информацию)

Что касается часового пояса, я бы добавил еще один столбец для хранения только индикации TimeZone.

Помните, что любой выбранный вами формат должен поддерживать согласованность между двумя датами, т. Е. Если D1> D2, то формат (D1)> формат (D2), таким образом, вы можете запрашивать в БД изменения с некоторой даты или запрашивать изменения между две даты

...