3

私はかなり複雑なシステムを設計中です。私たちの主な関心事の 1 つは、SQL Server のピア ツー ピア レプリケーションのサポートです。アイデアは、地理的に離れた複数のノードをサポートすることです。

2 つ目の懸念事項は、中間層で最新の ORM を使用することです。私たちが最初に選んだのは常に Entity Framework でした。これは主に、開発者が Entity Framework で作業することを好むためです。(彼らは LiNQ サポートが大好きです。)

だからここに問題があります：

ピア ツー ピア レプリケーションを念頭に置いて、すべてのテーブルの主キーに、uniqueidentifier をデフォルト値の newsequentialid() で使用することにしました。これにより、キーの競合を回避することとインデックスの断片化を減らすことのバランスが取れているように見えました。

ただし、現在のバージョンの Entity Framework には非常に奇妙な制限があることが判明しました。エンティティのキ​​ー列が一意の識別子 (GUID) である場合、データベースによって提供される既定値 (newsequentialid()) を使用するように構成することはできません。アプリケーション層は GUID を生成し、キー値を設定する必要があります。

だからここに議論があります：

  1. Entity Framework を放棄し、別の ORM を使用します。
    • NHibernate を使用し、LiNQ サポートをあきらめる
    • linq2sql を使用し、将来のサポートを断念します (DB 上の SQL Server にバインドされることは言うまでもありません)
  2. GUID を放棄し、別の PK 戦略を採用する
  3. アプリケーション層で順次 GUID (COMBs?) を生成する方法を考案する

私は linq2sql (私の開発者は linq2[stuff] が本当に好きです) と 3 でオプション 1 に傾いています。開発者の視点。

洞察や意見をいただければ幸いです。

4

6 に答える 6

8

私は Craig の提案を支持します - オプション 4.

中間層によって設定された GUID 列は、いつでも PRIMARY KEY (論理構造) として使用できます。

大規模なインデックス (つまり、テーブル) の断片化を回避するには、別のキー (理想的には INT IDENTITY 列) を CLUSTERING KEY として使用します。これは物理的なデータベース構造であり、主キーから分離できます。

デフォルトでは、主キーはクラスタリング キーですが、そうである必要はありません。実際、「継承」したデータベースでこれを行うだけで、パフォーマンスが向上し、断片化が大幅に減少しました。

マルク

于 2009-03-03T06:32:48.803 に答える
5

は？あなたの3つの選択肢は間違った選択だと思います。オプション 4 を検討してください。

4) エンティティ フレームワークを非順次のクライアント生成 GUID と共に使用します。

EF は、フレームワーク自体によって挿入された新しい行の DB サーバーによって生成された GUID を確認できませんが、DB サーバーで GUID を生成する必要はありません。エンティティ インスタンスを作成するときに、クライアントでそれらを生成できます。GUID の要点は、どこで生成してもかまわないということです。レプリケートされた DB によって生成された GUID に関しては、EF はそれらを問​​題なく認識します。

クライアント側の GUID はシーケンシャルではありませんが (Guid.NewGuid() を使用)、世界中で一意であることが保証されます。

これは、レプリケーションを使用した出荷用の本番ソフトウェアで行います。それは機能します。

于 2009-03-03T02:10:02.337 に答える
4

別のオプション (これが投稿された時点では利用できません) は、サーバー生成の GUID をサポートする EF 4 にアップグレードすることです。

于 2010-05-24T12:57:16.480 に答える
0

NewSequentialID（）の使用に本当に固執している場合は、ストアドプロシージャを使用できます。プロシージャの結果列を適切なプロパティにバインドできます。挿入されると、SQLで生成されたGUIDがオブジェクトにフィードバックされます。

残念ながら、他の操作はデフォルトを使用して正しく完了する場合でも、3つの操作（挿入、更新、削除）すべてに対してSPを定義する必要があります。また、SPコードを維持し、変更を加えるときにEFモデルと同期していることを確認する必要があります。これにより、追加のオーバーヘッドのためにこのオプションが魅力的でなくなる可能性があります。

http://blogs.msdn.com/bags/archive/2009/03/12/entity-framework-modeling-action-stored-procedures.aspxに段階的な例がありますが、これは非常に簡単です。

于 2009-04-06T19:42:51.097 に答える
0

ID列を使用してみませんか？マージレプリケーションを実行している場合は、各システムを個別のシードで開始し、一方向で動作させることができます（たとえば、ノードaは1で開始し、1を加算し、ノードbは0で開始し、1を減算します）...

于 2009-03-03T01:06:15.767 に答える
0

linqを使用して独自のormでnewseqidを使用します（それほど難しくありません）

于 2009-05-07T05:51:56.940 に答える