使用SQL Server FILESTREAM GUID作为主键

Question

我正在创建一个名为Photo的简单表，用于存储在User表中定义的人/团体的照片。我使用微软SQL Server的FILESTREAM功能，因为所有其他用户数据已经存储在SQL Server中，而且当它们直接与数据库条目相关联时，通过手动检索对象编写单独的方法不如这种方式更有意义。

每个用户一次只能有一个关联的照片（暂时是这样，但将来可能会改变），FILESTREAM需要一个GUID列来引用它存储到磁盘上的文件，所以这是我为Photo设计的模型：

UserID int NOT NULL UNIQUE
PhotoID uniqueidentifier ROWGUIDCOL NOT NULL
PhotoBitmap varbinary(MAX) FILESTREAM NULL

我的问题是（如果这个模型适用于我的应用程序），我应该使用PhotoID作为主键，因为它已经是唯一的并且是必需的吗？对我来说，这似乎比创建一个单独的INT列仅用于主键更简单，但我不知道这是否“正确”。

- Oran D. Lord

Answer 1

我个人在大多数主键和聚集键中使用 INT IDENTITY。

需要区分主键和聚集键。主键是逻辑结构，唯一标识行，必须唯一、稳定和非空。主键也可以使用GUID，因为它保证是唯一的。如果使用SQL Server复制，则GUID作为主键是一个不错的选择，因为在这种情况下，您需要一个唯一标识的GUID列。

SQL Server中的聚集键是物理结构，用于数据的物理排序，而且更难以正确设置。通常，在SQL Server上索引方面的专家Kimberly Tripp也要求良好的聚集键必须是唯一、稳定、尽可能窄，并且最好是增量的（INT IDENTITY就是）。

点击此处查看她有关索引的文章：

• GUID作为主键和/或聚集键
• 聚集索引之争仍在继续……
• 越来越大的聚集键——再次讨论聚集索引之争！
• 磁盘空间很便宜——这不是重点！

此外，请参阅Jimmy Nilsson的GUID作为主键的代价

一个GUID作为聚簇键是非常糟糕的选择，因为它宽，完全随机，从而导致索引碎片化和性能下降。此外，聚簇键行也存储在每个非聚簇（附加）索引的每个条目中，因此您真的希望它保持小巧 - GUID是16字节，而INT是4字节，并且具有多个非聚簇索引和几百万行，这会产生巨大的差异。

在SQL Server中，默认情况下，您的主键是聚簇键，但不一定非得这样。您可以轻松使用GUID作为非聚簇主键，INT IDENTITY作为聚簇键 - 这只需要稍微注意一下即可。

- marc_s