GUID应该用作许多表的外键

Question

我设计了一个数据库来使用UserID的GUID，但我添加了UserId作为许多其他表的外键，因为我打算拥有大量的数据库输入，我必须设计这很好。

我还使用ASP Membership表（不是仅限成员资格，用户和角色）。

所以目前我在每个其他表中使用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)}
...

Answer 1

最终答案是它真的取决于。

Microsoft已记录了每个here的性能差异。虽然文章与您的情况略有不同，因为您必须使用UNIQUEIDENTIFIER链接回asp成员资格，但许多讨论点仍然适用。

如果你必须创建自己的用户表，那么拥有自己的int主键更有意义，并使用GUID作为外键。它将单独的实体分开。如果将来某个时候您想为用户添加不同的成员资格，该怎么办？然后，您需要更新主键，该主键必须级联到任何引用此表的表，并且可能会受到很大的性能影响。如果它只是用户表中的唯一列，那么这是一个简单的更新。

Answer 2

所有二进制数据类型（uniqueidetifier是二进制（16））都可以作为外键使用。但GUID可能会导致另一个小问题作为主键。默认情况下，主键是群集的，但GUID是随机生成的，而不是按顺序生成IDENTITY，因此会经常拆分IO页面，导致性能下降一点。

Answer 3

我会继续你当前的设计。

如果由于比较字符串而不是整数而因为查询中的内部联接性能而感到担心，那么现在根本没有区别。