我和我的同事正在尝试确定哪种方法是为两个数据库表设计架构和键的更好方法。一种是很少改变的查找表。它有大约 700 行。另一个表引用查找表。随着时间的推移，该表将有数千行。在设计 B 中，查找表的主键由 3 个 varchar 组成。另一个表的主键由相同的 3 个 varchar 组成，并添加了两个日期字段。在设计 A 中，3 个 varchar 被替换为代理键。这 3 个 varchar 具有唯一约束 (UC)。
哪个设计更好？我的同事说，如果我们有代理键，那么当我们需要向用户显示数据时，在表上进行联接将会变得非常慢。此外，拥有一个仅用于使行唯一的键是浪费的。我的观点是，连接速度很快，并且存储 3 个 varchar 的额外数据是浪费的，因为它会在两个表中重复这些数据。
我们在 T-SQL Server 2008 中的带有 EF 5 的 WPF 桌面应用程序中使用它。代理键还是自然键？附图显示了两种不同的设计。
表上只有几千行，我认为您不会注意到任何差异。即使一个表有数百万行，另一个表也如你所说只有 700 行。 SQL-Server 几乎是为高效地进行连接而设计的，所以当你的同事声称连接到一个表时，他是不正确的。太小的（700行）表会影响效率。
设计 A 比 B 更好的一方面是较大的表 (PriceIndex) 会更窄，因此用于连接的索引也会更窄。 4 个字节而不是 90 个字节可以大大提高性能。您可能需要的所有其他包含代理键的复合索引在设计 A 中也会比在设计 B 中更窄。
设计 B 比 A 更高效的情况是涉及以下查询：GROUP BY两个表中的列。例如，如果您有一个查询GROUP BY Price, HubCode，在设计 B 中，您可以在这两列上添加复合索引，而在设计 A 中，这些列将位于单独的表中，并且您不能拥有包含来自 2 个表的列的索引。
另一个方面是是否还有其他表以这些列作为主键，比如说您是否有另一个表(HubCode)作为PK和另一个(HubCode, TimeFrame)另一个与(IndexCode, HubCode)也许还有另一个(IndexCode, HubCode, TimeFrame, StartDate, EndDate, CustomerID)。使用设计 B（所有表都具有自然键），涉及多个表的联接的多个复杂查询可以更加高效，因为可以消除一些中间联接。使用设计 A（代理键），无法跳过中间连接，并且当（中间）表很大时，查找成本可能会变得相当大。
最后，没有什么比测试您的数据、您期望表增长的大小以及您期望运行的查询类型更重要的了。
