3

さまざまな種類の RDBMS と通信するアプリケーションの分散システムを計画しています。要件の 1 つは、すべての RDBMS タイプで一貫した DateTime の処理です。すべての DateTime 値はミリ秒の精度である必要があり、TimeZone 情報を含め、1 つの列に格納する必要があります。

異なる RDBMS では日付と時刻の処理が異なるため、この場合、ネイティブの列の型に依存できないのではないかと心配しているため、別の解決策を考え出す必要があります。（ここで間違っていたら、道を教えてください。）

ソリューションは、それが何であれ、理想的には、SQL レベルでの簡単な並べ替えと比較を可能にする必要があります。読みやすさや SQL 日時関数を使用する機能など、その他の側面は重要ではありません。これはすべてゲートウェイ サービスによって処理されるためです。

DateTime 値を unsigned largeint 列型 (8 バイト) に格納するというアイデアをいじっています。問題のすべての RDBMS (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 であるため、TimeZone 情報を格納するために次の 3 桁 (A と BB でマーク) が残ります: AxxxxxxxxxxxxxxxxxBB.

0001..8000 の最大年スパンを考慮すると、A は 0 または 1 のいずれかになり、BB は 00 から 99 のいずれかになります。

そして今、質問：

  • 私の提案した解決策についてどう思いますか? それにはメリットがありますか、それとも単にばかげているだけですか？

  • 他に良い方法がない場合、残りの 3 桁を TimeZone 情報に最適に使用するにはどうすればよいでしょうか?

4

2 に答える 2

1

1970 年以降の日時情報をミリ秒単位で保存することをお勧めします (Java スタイル)。これは、日時情報を格納するための標準的な方法であり、さらに、提案よりもスペースの点で効率的です。あなたの提案では、一部の数字が「無駄」になっているためです。つまり、月の数字は（00〜99ではなく）00〜12しか保存できません。開発言語は指定されていませんが、日付をミリ秒に変換する多くのコード スニペットを見つけることができると確信しています。.NET で開発している場合、同様のティックの概念があります。（この情報も使用できます）

タイム ゾーンに関しては、別の列を追加して、TimeZone 表示のみを格納します。

選択した形式は、2 つの日付間の一貫性を維持する必要があることに注意してください。つまり、 D1 > D2 の場合、 format(D1)>format(D2) の場合、この方法で、ある日付以降の変更を DB にクエリしたり、2 つの日付間の変更をクエリしたりできます。

于 2009-01-09T11:51:04.177 に答える