我设计了一个数据库，为 UserID 使用 GUID，但我将 UserId 添加为许多其他表的外键，因为我计划有一个非常大的数字我必须设计好这个数据库输入。
我还使用 ASP 成员表(不只是成员、用户和角色的个人资料)。
所以目前我在每个其他表中都使用 GUID 作为 PK 和 FK，这可能是个糟糕的设计？
我认为可能更好并且是我问题的来源，我是否应该在用户表中添加 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)}
...
最佳答案
最终的答案是这真的取决于。
Microsoft 记录了每个 here 的性能差异.虽然这篇文章与您的情况略有不同，因为您必须使用 UNIQUEIDENTIFIER 链接回 asp 成员资格，但许多讨论点仍然适用。
如果您无论如何都必须创建自己的用户表，那么拥有自己的 int 主键并使用 GUID 作为外键会更有意义。它使单独的实体分开。如果将来某个时候您想为用户添加不同的成员资格怎么办？然后您需要更新一个主键，这将必须级联到任何引用它的表，并且可能会严重影响性能。如果它只是您的用户表中的一个唯一列，那么这是一个简单的更新。
关于sql-server - GUID 是否应该用作许多表的外键，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/10616978/