我正在创建一个简单的表，称为Photo存储表中定义的人员/组的照片User。我正在使用 Microsoft 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仅为主键创建单独的列更简单，但我不知道它是否“正确”。
我个人使用我INT IDENTITY的大部分主键和集群键。
您需要将主键分开，这是一个逻辑结构 - 它唯一标识您的行，它必须是唯一且稳定的，并且NOT NULL. AGUID也适用于主键 - 因为它保证是唯一的。GUID如果您使用 SQL Server 复制，作为主键的 A 是一个不错的选择，因为在这种情况下，无论如何您都需要一个唯一标识列GUID。
SQL Server 中的集群键是一种物理构造，用于对数据进行物理排序，要正确执行要困难得多。通常， SQL Server 上的索引女王Kimberly Tripp 还要求一个好的集群键是唯一的、稳定的、尽可能窄的，并且理想情况下是不断增加的（这INT IDENTITY是）。
在此处查看她关于索引的文章：
并参见 Jimmy Nilsson 的The Cost of GUIDs as Primary Key
A对于集群键GUID来说是一个非常糟糕的选择，因为它很宽，完全随机，因此会导致索引碎片和性能不佳。此外，集群键行也存储在每个非集群（附加）索引的每个条目中，所以你真的想保持小 -GUID是 16 字节与INT4 字节，并且有几个非聚集索引和几百万行，这有很大的不同。
在 SQL Server 中，默认情况下您的主键是您的集群键 - 但它不是必须的。您可以轻松地使用 aGUID作为您的非集群主键，并将 aINT IDENTITY作为集群键 - 只需稍加注意即可。