0

最近我们遇到了如下情况：

我们正在设计一个数据库，并预测数据将在 6 个月内显着增长到数百万条记录。我们希望每一行都应该有一个 Guid 作为唯一 ID，它允许我们稍后将数据移动到 OLAP/存档数据库，在身份和 Guid 键的许多参数之后，我们想出了 Guid 作为唯一 ID。但是，将 Guid 作为主键总是一个坏主意，因此我们将表的主键是一个 Identity 列。设计如下所示

用户：

| Id (PK, Identity)                                                 |
| UserId (Guid, Unique-constraint, non-clustered index)             |  
| Name                                                              |
| Email                                                             |
| ...                                                               |

备注：

| Id (PK, Identity)                                                 |
| NoteId (Guid, Unique-constraint, non-clustered index)             |
| UserId (Guid, Foreign Key to Users(UserId)                        |
| Title                                                             |
| Text                                                              |
| ...                                                               |

将数据移动到存档时，我们不再需要关心身份密钥。

这个设计有问题吗？表现如何？请给我建议，谢谢。

4

1 回答 1

1

即使您没有将 GUID 作为主键，您仍将其用于连接，从而为服务器增加工作量。

您是否有理由不使用 Users.Id 作为 FK 目标？

UserId (INT, Foreign Key to Users(Id)

请记住，您还想为上面的列建立索引，因此您最终仍然会在表上得到两个 GUID 索引，这可能是碎片化的，因为我敢打赌程序员正在应用程序层中制作随机 GUID，而不是您制作数据库中的 NEWSEQUENTIALID()？

于 2013-05-21T08:50:55.040 回答