整数を自動インクリメントする代わりに、IDフィールドとしてGUIDを使用する場合、ドメイン駆動設計を実装する方が簡単ですか？GUIDを使用すると、実際の値を取得するためにデータベースにジャンプする必要はありません。
3222 次
6 に答える
6
GUIDは簡単で、最適なように見えます。彼らはデータベースを扱う必要がないので、フロントエンドプログラマーを誘惑します。
一方、データベースの問題をあまり考えずに使用した場合の潜在的な欠点を見るときは、可能な限り警告します。
問題は、エンティティをデータベースに保存する前に、エンティティのIDを本当に知る必要があるかどうかです。本当？なぜ？
最終的にGUIDを使用することにした場合、およびデータベースバックエンドとしてSQL Serverを使用している場合（他のRDBMSについて十分な情報に基づいた提案を行うことはできません）、絶対に次のことを確認することを強くお勧めします。 GUIDは、テーブルのクラスタリングキーとして使用されていません。これはあなたのパフォーマンスを殺します-間違いなく。
主キーとしてGUIDを使用する場合は、代わりにクラスタリングキーとして、データベースへの影響が少ない他の列を使用してください。INTIDENTITYが最初の選択肢になります。
Kimberly Trippによるこれらの記事をチェックして、GUIDがSQL Serverデータベースのクラスタリングキーとして絶対に良いアイデアではない理由を確認してください-インデックス作成とインデックス作成のパフォーマンスの問題に関しては、彼女は究極の第一人者であり、これらのポイントをはるかに優れたものにすることができます私は今までできた：
マーク
于 2009-11-21T16:52:36.393 に答える
6
DDDの中心的な信条の1つは、永続性の無知です。そうです、GUIDは、永続ストアに依存することなく、オブジェクトに一意のIDを提供する最も簡単な方法です。
注意：GUIDを使用したデータベースのパフォーマンスが心配な場合は、COMBの使用を検討してください（特にSQL Serverのインデックスの断片化に）
于 2009-11-21T15:41:39.700 に答える
2
何を見ているのか混乱しないので、Guidsをお勧めします。また、これは冗談としてよく使われることも知っていますが、GUIDではなくuintを探していたシステムで発生した問題をデバッグする必要がありました。これにより、SharePointのテンプレートが非アクティブ化され、再アクティブ化する方法がなくなりました。根本的な問題が何であるかを発見するために2日かかりました。したがって、要約すると、Guid'sを使用します。
于 2009-11-21T15:33:53.057 に答える
2
整数の増分に対するGUIDの唯一の利点は、ID作成の分散化です。つまり、インクリメントする整数にはアトミックインクリメントと共有値の読み取りが必要ですが、GUIDは衝突の恐れがほとんどなく、独立して作成できます。
GUIDを使用すると、データベースを参照せずにエンティティを逆参照できるという提案については、質問に記載されていない他の情報がないため、どのようになっているのかわかりません。ここでの選択は、キーを使用するかどうかではなく、キータイプの1つです。キーが手元にあり、そのキーがデータベースを介して値またはエンティティにマップされている場合は、データベースを参照してキーを逆参照する必要があります。
于 2009-11-21T15:35:23.850 に答える
2
私は2つの理由でGUIDを使用します。
- IDは、作成されたコンテキスト内だけでなく一意であるため、同じタイプのデータのIDを異なる場所で生成できます。これは、データを相互に交換する複数のインストールが地理的に分散している場合、または切断されたシナリオで適しています。
- これは、IDを論理的な方法で処理したいという衝動に対抗しますが、開発者に値を「公正でID」と見なすように強制します。
ただし、これらの議論がドメイン駆動設計にのみ有効であるとは限りません。
于 2009-11-21T15:39:41.747 に答える
1
いいえ、絶対にありません。GUIDは、ドメインにリークすることを想定していない実装の詳細です。ID値オブジェクトが必要ですが、どのように実装してもかまいません。
于 2015-08-26T22:43:42.260 に答える