3

これは明らかな質問のようですが、良い答えを見つけるのにいくつか問題がありました。UTC 時間に敏感である必要がある n 層アプリケーションを構築しています。値を更新することができ、タイムスタンプが記録されます。これには、更新または挿入が日時列に影響を与えるデータベース内のトランザクションが含まれます。

コンテキストを提供するために、ほとんどの日時列に SQL 2008 R2 + と DATETIMEOFFSET(2) を使用しています。タイムスタンプの更新をストアド プロシージャに入れ、ネットワーク経由で渡す必要がないようにすることを検討しています。これにより、システムが成長するにつれて帯域幅が節約されます。これは良いことです...そして、共有データでデータが変更されたかどうか (最初に勝つかどうか) を検証するために使用できます。欠点は、アプリケーションのインスタンスで応答時間が遅くなると、最初にトランザクションを送信した人が勝てない可能性があることです。

このコンテキストで UTC 時刻データを処理するための理想的または推奨される方法は何ですか?

  1. SYSUTCDATETIME() OR ... を使用して SPROC に設定します。
  2. DateTimeOffset.Now または DateTime.UtcNow を使用してアプリケーションで設定します。

上記の 2 つの場合、これをプレゼンテーション レイヤーで起動し、サービスを介してドメイン レイヤーに渡すか、サービスのバックエンドでドメインにヒットしたときに設定することをお勧めしますか?

ご覧のとおり、ここには多くのオプションがあり、私はデータベースに傾倒しています...しかし、これを構築し続ける前に、アドバイスや警告の言葉をいただければ幸いです.

補足: 私は地理空間情報も追跡していますが、これは厳密なリアルタイム システムではありません。ユーザーリアルタイムで十分です。

更新: アプリケーションで DateTimeOffset を使用します。私の調査により、「最初にそれぞれの ToUniversalTime を呼び出すことにより、任意の 2 つの DateTimes を確実に比較できることがわかりました。この戦略は、そのうちの 1 つだけが "Unspecified" の DatTimeKind を持っている場合に失敗します。彼の失敗の可能性は別のものです。 DateTimeOffset を好む理由" - C# 4.0 一言で言えば、O'Riely の本です。

4

1 に答える 1

3

手順で設定することに投票します（または列のデフォルト、挿入の場合）。ユーザーがボタンをクリックしたときとデータベースでトランザクションがコミットされたときなどを区別するためにマイクロ秒の精度が必要でない限り、このすべての情報をすべてのレイヤーに渡す理由はありません。これは、分散アプリケーションを使用している場合に特に当てはまります。クライアント/サーバー アプリ用のエンド ユーザー ワークステーションは気にせず、すべての Web/アプリケーション サーバーの同期に依存したいですか? サーバーが異なるデータ センターにあり、すべてが異なるタイム ゾーンであり、一部は DST を監視し、一部は監視していないなどです。DateTime.UtcNowこれらの違いのほとんどをなくす必要がありますが、理由もなくすべてのデータを渡すことに戻ります。データベースは現在の時刻を認識しています。値を保存して、そのすべてのロジックをアプリケーションから除外します。

(また、UTC 時刻を保存している場合、本当に が必要DATETIMEOFFSETですか? もしそうなら、この情報がどのタイムゾーンから来たかを知るための手順が必要です。そうでない場合は、SMALLDATETIME/DATETIME/DATETIME2必要な精度に応じて使用する必要があります. )

于 2013-03-27T23:53:51.027 に答える