從主鍵分離聚集索引的實體框架

我有一個表模式，其中主鍵是uniqueidentifier，聚集索引是bigint類型的標識列。從主鍵分離聚集索引的實體框架

這個想法是，Guid索引可能會被分割，如果它將被分割，我更喜歡它不是聚集索引，因爲那樣會真的減慢插入。即我希望儘可能順序地插入行。

但是，我不希望羣集索引傳播到EF中的概念層。聚集索引只是所謂的記錄的物理位置，程序員不需要知道它的任何內容。就他們而言，他們只是在處理Guid PK。所以我從模型中刪除了財產。

然而，項目編譯卻抱怨說聚集索引列是不可空的，並且沒有默認值，其中任何一個都是無意義的，因爲它是一個標識列，既不能有默認值也不可以爲空。

我該怎麼做才能讓項目編譯？

注意：我不想要關於Guid vs. Sequential Guid vs. Int Id的爭論。該系統必須能夠擴展，這意味着我所關心的Guid PK。

來源

2012-05-12 Alwyn

如果您沒有使用bigint列，那麼這對您有什麼幫助？ – scottm

他正在使用它作爲聚簇索引（以提高數據庫性能）。 –

@ypercube這沒有任何意義。如果您不在該列上查詢，那麼您沒有使用該索引。如果OP只會在GUID列上查詢，那麼這可能就是聚簇索引。如果實際上需要更多的有序索引，那麼應該使用順序的GUID。通過添加第二個索引，您只會增加插入一行所需的時間，並通過執行OP建議的操作（稍微）增加查詢記錄所需的時間。 – scottm

您應該檢查EDMX中物業的EntityKey值設置爲true。

來源

2012-05-12 19:37:37 scottm

我不能這樣做，它不是實體鍵......這就是映射條目的樣子一切都是那裏很好，除了EF需要兌現StoreGeneratedPattern並停止將其視爲編譯時異常。 – Alwyn

您可以在單個實體上擁有多個實體鍵。 – scottm

我添加了叢集編號到像這樣的EntityKey值：的EDMX內部。看起來不正確，並且稍後可能會成爲問題，因爲將來可能會動態分割表，因爲ClusterID可能會更改，並且EF會認爲緩存中的實體是相同的實體。寧願一個更清潔的解決方案，但這至少值得大拇指。 – Alwyn

從主鍵分離聚集索引的實體框架

回答

相關問題