SQL:到主键还是不到主键？

Question

我有一个包含用户设置集的表，它有以下各列：

UserID INT
Set VARCHAR(50)
Key VARCHAR(50)
Value NVARCHAR(MAX)
TimeStamp DATETIME

UserID以及Set和Key是唯一的。因此，特定用户在一组特定设置中不能有两个相同的密钥。设置是按集合检索的，因此，如果用户请求某个集合中的某个密钥，则会下载整个集合，以便下次需要同一集合中的密钥时，不必将其转到数据库。

我是应该在所有三列(userid、set和key)上都创建一个主键，还是应该创建一个具有主键的额外字段(例如，一个名为SettingID的自动增量整数，我猜这不是个好主意)，或者不创建主键，只创建一个唯一的索引？

--更新

澄清一下:这是行表的末尾，它无论如何都不会连接在一起。UserID是Users表的FK。Set不是FK。它几乎就是我的GUI的助手表。举个例子:用户在第一次访问网站的某些部分时，会得到一个帮助气球，如果他们想要的话，可以关闭它。一旦他们点击它离开，我会添加一些设置到"GettingStarted“设置，这将表明他们的帮助气球X已被禁用。下一次当用户来到同一页面时，该设置将声明不应再显示帮助气球X。

Answer 1

我应该在所有三列(userid, set, and key)上创建主键吗？

做这个吧。

使用surrogate primary key将产生一个不用于其他目的的额外列。

创建带有代理主键的UNIQUE INDEX与创建非集群PRIMARY KEY是相同的，并且将导致额外的KEY lookup，这对性能更差。

创建一个没有PRIMARY KEY的UNIQUE INDEX将导致一个HEAP-organized表，这将需要一个额外的RID lookup来访问值:也不是很好。

Answer 2

拥有复合的唯一键通常不是一个好主意。

将任何与业务相关的数据作为主键也会给您带来麻烦。例如，如果您需要更改该值。如果无法在应用程序中更改该值，则可以在将来更改，或者必须在升级脚本中更改。

最好创建一个代理键，这是一个没有任何商业意义的自动编号。

在更新后编辑：

在这种情况下，您可以考虑让在概念上没有主键，并使这三列成为组合惟一键的主键(使其可更改)。

Answer 3

你有多少把钥匙和一套钥匙？它们是否需要是varchar(50)，或者它们是否可以指向查找表？如果你可以将这个集合和键转换成SetId和KeyId，那么你就可以在3个整数值上创建你的主键，这将会快得多。