組合鍵字段的最佳順序是什麼？

LeagueID
MatchID
SomeData

甲A聯賽將舉辦很多比賽。通常每個聯盟都會使用自己的本地數據庫，所以本地數據庫的所有記錄中的聯盟ID字段都是相同的。聯盟每年一次將其數據上傳到國家主管部門，然後聯盟ID將有必要分配具有相同MatchID的匹配。

實現複合主鍵（使用EF Fluent API）的最佳方式是什麼？

Entity<Match>.HasKey(match=>new {match.LeagueID,match.MatchID})

Entity<Match>.HasKey(match=>new {match.MatchID,match.LeagueID})

對人眼的順序聯賽 - 比賽是合乎邏輯的，因爲它會保留特定聯賽的比賽一起。但是我明白，在編寫組合鍵時，首先使用最具區分性的字段對性能的原因非常重要。

來源

2013-02-01 Dabblernl

您可以通過使用HasColumnOrder

來源

2013-02-01 14:31:41 Tasio

是的，但問題是關鍵的順序 –

好的，那麼問題是更多關於數據庫實現，而不是EF本身。「對人眼命令聯賽 - 比賽是合乎邏輯的」比特是無關緊要的。 – Tasio

選擇在數據庫中的字段的順序，我認爲你可以有你的蛋糕和熊掌兼得。

數據庫
當實現在數據庫通常與更具選擇性的字段（一個或多個）更窄的密鑰的密鑰將產生更好的性能。這適用於單個&組合鍵。我通常說，因爲一個更具選擇性的索引並不能真正匹配你的查詢模式，這可能是無用的。例如，在您的組合鍵中，如果MatchID是第一個（更具選擇性），但您更頻繁地通過LeagueID（較少選擇性）查詢，則選擇性將對您起作用。

我認爲真正的問題不在於索引A或B更具選擇性，而是「您是否有適合您查詢的索引？」（並強化數據完整性，但這是一個不同的討論）。所以你需要弄清楚如何你查詢這張表。如果您查詢的：

LeagueID大部分時間 - 指數LeagueID, MatchID
MatchID大部分時間 - 指數MatchID, LeagueID
複合LeagueID & MatchID大部分的時間 - 指數 MatchID, LeagueID
混合包 - 您可能需要爲每個訂單指定兩個索引，但您必須弄清楚維護兩個索引的額外開銷是否值得插入/更新/刪除。

EF &查詢
在大多數情況下，列在你的查詢的順序（或你建立在EF匹配的方式）不會有所作爲。含義where [email protected] and [email protected]將提供相同的查詢計劃&性能爲where [email protected] and [email protected]。

假設你使用的是SQL Server，你寫的where子句的順序很少。在線書籍可以簡潔地解釋問題，stating：

邏輯運算符的求值順序可能因查詢優化程序的選擇而異。）。

來源

2013-02-01 14:31:57 EBarr

+1 EBarr，很好地描述了情況.... –

謝謝 - 它通常是我耳朵之間混亂的混亂：-D – EBarr

*當a = @ a和b = @ b *和*當b = @ b和a = @ a *只會在數據庫引擎評估所有條件時執行相同的操作。我猜想當第一個是假的時，引擎不會評估第二個條件。就像VB'AndAlso'或者C＃'&&'操作符一樣。 – Dabblernl

組合鍵字段的最佳順序是什麼？

回答

相關問題