代码之家 › 专栏 › 技术社区 › Gideon

SQL:是否为主键?

primary-key indexing sql

Gideon · 技术社区 · 17 年前

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

UserID以及Set和Key是唯一的。因此,特定用户在一组特定设置中不能有两个相同的键。设置是按集合检索的,因此,如果用户请求某个集合中的某个密钥,整个集合都会被下载,这样下次需要同一集合中的某个密钥时,它就不必进入数据库。

-----更新-----

举个例子:用户第一次访问网站的某个部分时会得到一个帮助气球,如果他们愿意,可以关闭它。一旦他们点击它离开,我将添加一些设置到“GettingStarted”集合,该集合将声明他们的帮助气球X已被禁用。下次当用户访问同一页面时,设置将声明不应再显示帮助气球X。

8 回复 | 直到 17 年前

Stefan Steinegger 17 年前

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

最好创建一个代理密钥,一个没有任何商业意义的自动编号。

编辑更新后:

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

Quassnoi 17 年前

(userid, set, and key)

做这个。

使用代理主键将产生一个额外的列,该列不用于其他目的。

UNIQUE INDEX 与代理主键一起使用与创建非群集主键相同 PRIMARY KEY KEY lookup 这对性能更不利。

创建一个没有 主键 将导致 HEAP-organized 需要另加一张桌子的桌子 RID lookup 访问值:也不是很好。

Robin Day 17 年前

你有几把钥匙和几套钥匙?它们需要是varchar(50)还是可以指向查找表?如果可以将此集合和键转换为SetId和KeyId,则可以在3个整数值上创建主键,这将更快。

Jonathan 17 年前

我可能会尝试确保UserID是唯一的标识符,而不是在整个代码中都有重复的UserID。复合键在代码生命的后期往往会变得混乱。

我假设这是某种配置值的查找字段,因此如果是这种情况,您可能会使用复合键。数据已经存在。您可以使用主键保证它的唯一性。如果您改变了主意,后来决定它不适合您,您可以轻松地添加一个SettingId,并将原始复合键设置为唯一索引。

smok1 17 年前

创建一个单独的主键。无论bussines逻辑将如何变化,您的Key VARCHAR(50)字段都必须应用哪些新规则-拥有一个主键将使您完全独立于bussines逻辑。

rein 17 年前

就我个人而言,我会创建另一个FK列,并在其他三个列上设置一个唯一的约束。这使得该表的外键更容易吞下。

HLGEM 17 年前

我不是复合键的支持者,但在本例中,作为一个行尾表,它可能是有意义的。但是,如果由于插入时一个或多个值未知,因此在这三个字段中的任何一个字段中允许为空,则可能会有困难,并且唯一索引可能更好。

Rob 15 年前

最好将UserID设置为32位newid()或唯一标识符,因为UserID设置为int会向用户提示可能的UserID。这也将解决您的复合密钥问题。