6

GUIDを使用するデータベースを設計しましたUserIDが、他の多くのテーブルに外部キーとして追加UserIdしました。非常に多くのデータベース入力を計画しているため、これを適切に設計する必要があります。

ASPメンバーシップテーブルも使用します（メンバーシップ、ユーザー、およびロールのみのプロファイルではありません）。

したがって、現在、他のすべてのテーブルでGUIDをPKおよびFKとして使用していますが、これはおそらく悪い設計ですか？私が思うものはおそらくより良いものであり、私の質問のソースです。UsersテーブルUserId(int)を主キーとして追加し、このフィールドを他のテーブルやユーザーへの外部キーとして使用GUID UserIdして参照する必要がありますaspnet_membershipか？

aspnet_membership{UserID(uniqueIdentifier)}
Users{
UserID_FK(uniqueIdentifier) // FK to aspnet_membership table
UserID(int) // primary key in this table --> Should I add this
...
}
In other tables user can create items in tables and I always must add UserId for example:
TableA{TableA_PK(int)..., CreatedBy(uniqueIdentifier)}
TableB{TableB_PK(int)..., CreatedBy(uniqueIdentifier)}
TableC{TableC_PK(int)..., CreatedBy(uniqueIdentifier)}
...
4

3 に答える 3

2

すべてのバイナリデータ型（一意化子はbinary（16））は、外部キーとして問題ありません。ただし、GUIDは主キーとして別の小さな問題を引き起こす可能性があります。デフォルトでは、主キーはクラスター化されていますが、GUIDはIDENTITYとして順番に生成されるのではなくランダムに生成されるため、IOページが頻繁に分割され、パフォーマンスが少し低下します。

于 2012-05-16T11:22:13.050 に答える
2

最終的に答えはそれが本当に依存するということです。

Microsoftは、それぞれのパフォーマンスの違いをここに文書化しています。記事は状況によって少し異なりますが、aspメンバーシップにリンクするには、UNIQUEIDENTIFIERを使用する必要があるため、多くの議論のポイントが引き続き適用されます。

とにかく独自のusersテーブルを作成する必要がある場合は、独自のint主キーを用意し、GUIDを外部キーとして使用する方が理にかなっています。個別のエンティティを個別に保持します。将来、ユーザーに別のメンバーシップを追加したい場合はどうなりますか？次に、主キーを更新する必要があります。これは、これを参照するテーブルにカスケードする必要があり、パフォーマンスに大きな影響を与える可能性があります。ユーザーテーブルの一意の列である場合は、単純な更新です。

于 2012-05-16T11:34:17.517 に答える
0

私はあなたの現在のデザインを進めます。

intではなく文字列を比較するためにクエリの内部結合のパフォーマンスが心配な場合は、最近ではまったく違いはありません。

于 2012-05-16T10:55:25.477 に答える