假设我有一个包含以下字段的表:
- 联赛ID
- 匹配ID
- 一些数据
一个联赛会举办很多场比赛。通常每个联盟都会使用自己的本地数据库,因此该本地数据库的所有记录中的 LeagueID 字段都是相同的。联盟每年将其数据上传到国家当局一次,然后需要 LeagueID 来区分具有相同 MatchID 的比赛。
实现复合主键的最佳方法是什么(使用 EF Fluent API)?
Entity<Match>.HasKey(match=>new {match.LeagueID,match.MatchID})
或者
Entity<Match>.HasKey(match=>new {match.MatchID,match.LeagueID})
对于人眼来说,联赛 - 比赛的顺序是合乎逻辑的,因为它将特定联赛的比赛放在一起。但我明白,在编写复合键时,出于性能原因,首先使用最具辨别力的字段非常重要。
最佳答案
我认为你可以鱼与熊掌兼得。
数据库
在数据库中实现键时,通常具有更多选择性字段的较窄键将产生更好的性能。这适用于单键和复合键。我一般说的是,因为与您的查询模式并不真正匹配的更具选择性的索引可能毫无用处。例如,在您的组合键中,如果 MatchID
位于第一个(选择性更强),但您通过 LeagueID
查询更频繁(选择性较低),那么选择性将对您不利。
我认为,真正的问题不是索引 A 或 B 更具选择性,而是“您是否有适合您查询方式的索引?” (并强制数据完整性,但这是一个不同的讨论)。因此,您需要弄清楚如何查询该表。如果您通过以下方式查询:
LeagueID
大部分时间 -- 索引LeagueID, MatchID
MatchID
大部分时间 -- 索引MatchID, LeagueID
- 大多数情况下是复合
LeagueID
和MatchID
-- 索引比赛ID、联赛ID
- 一个混合包 - 您可能需要每个订单一个索引,但您必须弄清楚维护两个索引的额外开销是否值得在插入/更新/删除时付出代价。
EF 和查询
在大多数情况下,查询中的列顺序(或在 EF 中构建匹配的方式)不会产生影响。这意味着 where a=@a and b=@b
将产生与 where b=@b and a=@a
相同的查询计划和性能。
假设您使用的是 SQL Server,则编写 where 子句的顺序并不重要。网上的书简洁地解释了这个问题,stating :
The order of evaluation of logical operators can vary depending on choices made by the query optimizer. ).
关于entity-framework - 复合键字段的最佳顺序是什么?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/14648407/