为什么将int用作查找表的主键？

我想知道为什么我应该使用int作为查找表的主键，而不是仅使用lookup值作为主键（在大多数情况下为字符串）。

我知道，如果将nvarchar（50）而不是int链接到具有许多记录的表，则会使用更多空间。

另一方面，直接使用查找值基本上可以节省我们进行连接的时间。我可以想象，如果始终需要加入，这将节省很多钱（我们正在开发一个Web应用程序，因此这很重要）。

除了将int主键用作“标准操作”以外，还有什么好处？

您问题的答案是合乎逻辑的，而不是物理上的-由于业务原因，您查找的值可能会更改。例如，如果您通过电子邮件地址为客户建立索引，那么当电子邮件地址更改时会发生什么？显然，这并不适用于您的所有查找表，但是在整个应用程序中以相同的方式进行操作的好处在于，它使您的代码更简单。如果内部所有内容都是整数→整数关系，则可以满足要求。

只需阅读您对Sandy的评论-也许在这种情况下，您真正​​想要的是Check Constraint，而不是外键/查找表，例如：

create table icecream (flavour varchar(10))
go
alter table icecream add constraint ck_flavour check (flavour in ('Orange', 'Pista', 'Mango'))
go
insert into icecream (flavour) values ('Orange')
go
insert into icecream (flavour) values ('Vanilla')
go

运行此命令，您将获得：

(1 row(s) affected)
Msg 547, Level 16, State 0, Line 1
The INSERT statement conflicted with the CHECK constraint "ck_flavour". The conflict occurred in database "GAIUSDB", table "dbo.icecream", column 'flavour'.
The statement has been terminated.

这是一种高效的高性能方法，但是当然缺点是添加新的样式意味着代码更改。我建议不要在应用程序中执行此操作-因为然后您需要在连接到该数据库的每个应用程序中执行此操作，因此这是最干净的设计，因为只有一条代码路径可以进行验证。

“直接使用查找值” –它与查找表的实际目的有点矛盾。为什么要保留这样一张桌子？如果不是查找。
可能是我误解了您的问题。这是来自msdn的查找表定义

查找表用于根据另一个表中外键字段的值显示来自一个表的信息。例如，考虑销售数据库中的订单表。订单表中的每个记录都包含一个CustomerID，该ID指示哪个客户下了订单。CustomerID是指向“客户”表中客户记录的外键。呈现订单列表（来自“订单”表）时，您可能希望显示实际的客户名称，而不是CustomerID。由于客户名称在customers表中，并且您要显示Orders表中的数据，因此需要创建一个查找表，该表使用Orders记录中的CustomerID值，并使用该值导航关系并返回更多可读的客户名称。

您可以忽略查询表的目的吗？是否用于存储如下所示的静态数据，并且这些记录不是其他表记录的输入？

调味 桌

Orange  
Pista  
Mango

如果以上是您的情况，那么我建议您不要使用查找表；可能在您的Web应用程序中将这些列表值硬编码。这样，您可以避免不必要的数据库查询。

由于您使用“专门用于查找表”来限定问题的范围，因此答案可能会简化为“节省空间”。

我认为，如果删除该限定词，您的问题将变成“为什么要使用替代键而不是自然键？” 我写了以下内容以支持代理键：

“迁移一个整数值而不是一个更宽的复合键具有很多好处。与迁移复合键相比，它在整个物理模型中提供了很好的一致性，与节省成本相比，节省了更多空间，并减少了I / O；尤其是在迁移良好的情况下，标准化模型。此外，它们简化了对模型和查询联接的理解。”

这很大程度上是为什么它“成为标准的事情”的原因。不幸的副产品是人们扔了一个替代密钥，却不认为候选密钥是什么...但是现在我们已经超出了您的问题了：）

我一直使用的原因之一是，如果有人在查询表中拼错了一个值，例如说Oraneg而不是Orange，则更改查询表中的值非常容易。

具有数字主键的查找表仅需要在查找表中更改该值。

使用值作为其主键的查找表将需要在查找表以及使用该表的主表中的每个记录中进行更改。

定义ID时，还可以保证唯一性。但是，当您将电子邮件作为唯一标识符时，您会将唯一性责任转移到不受信任的第三方。