3

現在、日付の保存に関する最善の方法について議論しており、経験豊富なコメントをいただければ幸いです。「方法」ではなく「理由」を探してください。

シナリオ：

クライアント (複数のタイムゾーンにまたがる) がトランザクション データを作成できるようにするシステムを開発しています。サインアップ時に、クライアントはタイムゾーンを指定します。システムの大部分は、トランザクション データに関する日付と時刻に関連するレポートを実行するクライアントを中心に展開します。

トランザクションの日付フィールドを格納する最良の方法に関する多くの質問とコメントを読みました。ほとんどの場合、UTC として格納し、さまざまな日付と時刻に関連する関数を実行して、さまざまなタイムゾーンで時刻を計算し、選択レポートを実行します。

私たちの質問は、なぜ UTC で格納するためにわざわざわざわざ行くのかということです。日付を UTC で格納する利点は何ですか。私たちの観点からは、クライアントの指名されたタイムゾーンがあるため、日付/時刻を正しいタイムゾーンに保存すると、トランザクションごとに 1 回実行される計算になります。その後、すべてのレポートは日付変換計算なしで機能します。

私たちが読んだ質問やコメントのほとんどが「どのように」について言及しているため、「なぜ」について見逃している何かがあるに違いないと考えています。

つまり、要約すると、決定を下す前に、何かを見逃していました-「日付をUTCとして保存する必要がある」という絶対的な理由はありますか?

読んでいただきありがとうございます - コメントをお待ちしております。

4

3 に答える 3

1

なぜわざわざ UTC で保存する必要があるのでしょうか。

UTC で時刻を保存する手間はありません。userIMOは、テーブルのすべてのレコードが異なるタイムゾーンにあり、テーブルとの関係がどのタイムゾーンにあるかを示すのではなく、すべてが同じタイムゾーンにある場合、日時フィールドを維持する方が簡単です（または、ばかげたアプローチでさえ、オフセットを次のよう+02:00に保存することです追加フィールド）。

サインアップ時に、クライアントはタイムゾーンを指定します。

機能を追加するとどうなるかを考えてみましょう。

  • ユーザーがタイムゾーンを変更するとどうなりますか?
  • ユーザーがリクエストごとにタイムゾーンを指定できるようにシステムをアップグレードするとしたらどうでしょうか?
  • 等

「日付をUTCとして保存する必要がある」という絶対的な理由はありますか?

そうではありません。それはすべてあなたのデザインに関するものです。あなたが選んだものは、あなたが扱うものです。将来のアップグレードなどのために、何が簡単になるかを考えてください。

于 2013-09-25T11:21:09.790 に答える
0

いいえ、私の意見では、これには「必須」はありません! これは完全に設計上の問題です。使用するものを選択することで、物事が機能する方法が決まります。どちらの場合も、UTC の使用を提案している人々は、それがよく知られており、検証されているため、単なる参照の問題です。プログラムがどれほど大きくなっても、クライアントがどこにいても、参照は常にそこにありますが、別のタイム ゾーンを使用すると、同じように動作しますが、選択したタイム ゾーンが参照になります。状況によっては誤解を招きますが、管理された環境ではまったく同じです。私はあなたの質問に答えたことを願っています。

于 2013-09-25T10:57:42.130 に答える