6

我设计了一个使用 GUID 的数据库，UserID但我将UserId其作为外键添加到许多其他表中，并且由于我计划拥有大量数据库输入，因此我必须将其设计好。

我还使用 ASP Membership 表（不仅仅是配置文件成员、用户和角色）。

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

3 回答 3

2

所有二进制数据类型（唯一标识符是二进制（16））都可以作为外键。但是 GUID 作为主键可能会导致另一个小问题。默认情况下主键是集群的，但是GUID是随机生成的，不像IDENTITY那样顺序生成，所以会频繁的拆分IO页面，会造成一点性能下降。

于 2012-05-16T11:22:13.050 回答
2

最终的答案是，这真的取决于。

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

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

于 2012-05-16T11:34:17.517 回答
0

我会继续你目前的设计。

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

于 2012-05-16T10:55:25.477 回答