3

新しい中間層にはLINQtoSQLとWCFを使用しており、実際のLINQクラスを使用するのではなく、データ転送オブジェクトを使用してネットワークを通過させています。更新が正しく機能し、同時実行が正しく処理されるようにするために、ここで概説するメソッドのいずれか（タイムスタンプまたは行バージョンに基づくLinq Table Attach（））を使用します。

読み取り時間を節約するために、基本的には、テーブルでタイムスタンプ/行バージョン列を使用するか、デフォルトと更新トリガーを備えた日時列を使用できます。どちらの方法でも、毎回新しく生成された値を取得する列を取得できます。挿入または更新が発生し、その列はLINQが同時実行性をチェックするために使用する列です。

私の質問は-どちらが良いですか？多くのテーブルに「UpdatedWhen」の日時列がすでにありますが（すべてではありません-質問しないでください）、デフォルトとトリガーを追加するか、rowversionを追加するだけです（使用する必要があります）今のところ、タイムスタンプの構文は、各テーブルに対してSQL2005をしばらくサポートしているため、どちらの方法でも、DBを機能させるために変更しているので、パフォーマンスに違いがあるかどうかを知りたいです。これら2つの選択肢の間に注意すべき他の重要な違い。私はウェブとここSOで検索しようとしましたが、今のところ運がありません。ありがとう。

4

2 に答える 2

4

私は最近同様の決定をしなければなりませんでした。

最初に行バージョンソリューションを試しました。
私が見つけた不利な点：

  • LINQ-to-SQLでの不便な使用法で、フィールドをbyte[]にマップしました。バイト配列を比較すると、コードがきれいに見えません
  • 理論的rowversionにはロールオーバーして0から再開できるため、高い行rowversionは必ずしも古い行であるとは限りません。
  • Rowversionは、行の更新時に更新されますが、私の場合は望ましくありませんでした。行のバージョンに影響を与えないように、一部の列を除外する必要がありました。トリガーを使用すると、あらゆるレベルの柔軟性を実装できます。

その結果、デフォルトの制約と更新トリガーを使用してdatetime2列を使用し、値をsysutcdatetime（）に設定しました
。このタイプの精度は100ナノ秒（精度7桁-23：59：59.9999999）
です。可能ですが、同じ値の生成を2回見たことはありません。しかし、私の場合、重複があっても問題はありません。それが私にとって重要である場合、私は一意の制約を追加し、これが失敗するかどうかを確認します。

この値は夏時間の影響を受けないため、sysutcdatetime（）を使用しました。

于 2011-05-07T18:22:04.160 に答える
3

同時実行性チェックにタイムスタンプ列を使用することに傾倒します。1つ-トリガーはパフォーマンスにいくらかの影響を及ぼし、2つ-日時列を使用すると、SQLおよびC＃のDateTime列の精度に制限されます。

MSDN：

日時の値は、.000、.003、または.007秒の増分に丸められます。

あなたはSOを見たいかもしれません：c＃のDateTimeとSQLサーバーのDateTimeの間に違いはありますか？およびMSDN：詳細についてはdatetime（Transact-SQL）を参照してください。

于 2011-05-06T17:42:02.173 に答える