アドバイスをお願いします:Entity Framework を使用する場合の SQL Server ID キーと一意の識別子キー

StackOverflow https://stackoverflow.com/questions/604273

質問

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

2 番目の懸念は、中間層で最新の ORM を使用することです。私たちが常に最初に選択するのは Entity Framework です。これは主に、開発者が Entity Framework を使用することを好むためです。(彼らは LiNQ サポートを気に入っています。)

そこで問題は次のとおりです。

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

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

そこで議論は次のとおりです。

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

私は linq2sql のオプション 1 (私の開発者は linq2[stuff] がとても気に入っています) と 3 に傾いています。その主な理由は、私たちが目指しているレプリケーション スキームをサポートしながら、開発者の観点から物事を正常に保つための代替キー戦略について、私がやや無知であるためです。

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

役に立ちましたか？

解決

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

他のヒント

私は Craig の提案に賛成します - オプション 4。

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

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

デフォルトでは、主キーはクラスタリング キーですが、必ずしもそうである必要はありません。実際、「継承」したデータベースでこれを実行することで、パフォーマンスが向上し、断片化が大幅に減少しました。INT IDENTITY 列を追加し、その小さな、増加し続ける、決して変更されない INT にクラスタリング キーを配置しました。これは、魔法のように機能します。

マルク

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

4) Entity Framework を使用する 非順次的, 、クライアントが生成した GUID。

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

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

これは、レプリケーションを使用した本番ソフトウェアの出荷時に行われます。それ する 仕事。

なぜ ID 列を使用しないのでしょうか?マージ レプリケーションを実行している場合は、各システムを個別のシードで開始して一方向に動作させることができます (例:ノード a は 1 から開始して 1 を加算し、ノード b は 0 から開始して 1 を減算します)...

NewSequentialID() の使用にどうしても行き詰まっている場合は、ストアド プロシージャを使用できます。プロシージャからの結果列を適切なプロパティにバインドでき、挿入されると、SQL で生成された GUID がオブジェクトにフィードバックされます。

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

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

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

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top