15

asp.net mvcでWebアプリケーションを実行していて、エンティティのlongデータ型とGuidデータ型のどちらかを選択していますが、どちらが優れているかわかりません。長い方がはるかに速いと言う人もいます。Guidにもいくつかの利点があるかもしれません。誰もが知っていますか？

4

3 に答える 3

20

GUIDが不適切になる可能性がある場合

GUIDは大きいため、ほとんどの場合遅くなります。これにより、インデックスが大きくなります。それはあなたのテーブルを大きくします。つまり、テーブルの全体または一部をスキャンする必要がある場合は、時間がかかり、パフォーマンスが低下します。これは、レポートベースのシステムにおける大きな懸念事項です。たとえば、ファクトテーブルは通常、その長さが重要であるため、ファクトテーブルの外部キーとしてGUIDを使用することはありません。これは、ファクトテーブルが部分的にスキャンされて集計が生成されることが多いためです。

また、「ロング」を使用することが適切かどうかも検討してください。それは非常に大きな数です。ある時点でテーブルに20億を超えるエントリがあると思われる場合にのみ必要です。私がそれらを使用することはめったにありません。

GUIDは、使用とデバッグが難しい場合もあります。「顧客レコード10034に問題があります、フランク、チェックしてください」と言うのは、「{2f1e4fc0-81fd-11da-9156-00036a0f876a}に問題があります...」と言うよりもはるかに簡単です。必要なときにクエリを入力します。

ああ、同じGUIDを2回取得することは決してないというわけではありません。非常に大規模で接続されていないシステムで発生することが知られているため、ほとんどのアプリでは設計しませんが、これを検討する必要があります。

GUIDを適切にできる場合

GUIDは、エンティティが作成されてから同期される切断されたシステムで作業している場合に適しています。たとえば、誰かがモバイルデバイスのデータベースにレコードを作成して同期した場合、またはエンティティが別のブランチオフィスで作成され、夜間に中央ストアに同期された場合です。それは彼らがあなたに与える一種の柔軟性です。

GUIDを使用すると、特定のORMシナリオで、エンティティをデータベースに永続化せずに関連付けることができます。Linq to SQL（およびEF）にはこの問題はありませんが、キーを取得するためにデータベースに変更を送信しなければならない場合があります。

クライアントでGUIDを作成する場合、作成するGUIDはシーケンシャルではないため、DBでのページ分割が原因で、挿入のパフォーマンスが低下する可能性があります。

私のアドバイス

ここで考慮すべきことがたくさんあります。私の投票は、説得力のあるユースケースがない限り、それらを使用しないことです。パフォーマンスが本当に目標である場合は、テーブルを小さくしてください。フィールドを小さくしてください。DBインデックスを小さく選択的にしてください。

于 2010-02-09T11:51:47.197 に答える
3

サイズ： Longは8バイトですGuidは16バイトです

GUIDは確実 に一意になる可能性が高く 、データベース内の個々のレコードの識別に使用するのが最適です。

long（DBのID）は、テーブル内の一意のレコードを表す場合がありますが、次のように1つ以上の異なるテーブルに同じID（ID）で表されるレコードがある場合があります。

TableA: PersonID int, name varchar(50)
TableB: ProductID int, name varchar(50)

SELECT PersonID from TableA where name =''
SELECT ProductID from TableB where name =''

どちらも同じ値を返すことができますが、GUIDの場合：

TableA: PersonID uniqueidentifier, name varchar(50)
TableB: ProductID uniqueidentifier, name varchar(50)

SELECT PersonID from TableA where name =''
SELECT ProductID from TableB where name ='

2つのテーブルから返されるidと同じ値を持つことはめったにありません

こちらをご覧ください

于 2010-02-09T11:26:01.063 に答える
2

Guidを使用すると、Guid.NewGuid（）の値を割り当てるだけで、APIに「新しい」エンティティを簡単に作成できます。データベースからの自動インクリメントされたキーに依存しないため、これにより、ドメインモデルが基盤となる永続性メカニズムからより適切に分離されます。

欠点として、SQL Serverでクラスター化インデックスとしてGuidを使用する場合、テーブルの最後に新しい行が追加されることはめったにないため、挿入にコストがかかるため、インデックスを頻繁に再構築する必要があります。

もう1つの問題は、明示的な順序を指定せずにそのようなデータベースから選択を実行すると、本質的にランダムな順序で結果が得られることです。

于 2010-02-09T11:30:02.160 に答える