核心數據性能是否更好，屬性更少？

我有一個名爲DiveSite的核心數據實體，它具有大量屬性，其中很多屬性代表影響潛水站點的功能或條件的布爾值。核心數據性能是否更好，屬性更少？

其實，我有這麼多的屬性，即Xcode中給了我一個警告 - 「配置錯誤的實體 - DiveSite擁有超過100種性能;考慮更淺的實體層次或反規範化屬性」

許多屬性可能是分組減少了實體上屬性的總數 - 我可能會將布爾變量組變成一系列整數，並進行邏輯並檢查我想要的因素。

我也意識到，我可以讓這些組分爲單獨的實體 - 其中一些將有1-1的關係和一些1-多關係

在性能方面會改變我的DiveSite實體少屬性是一件積極的事情嗎？

如果是這樣，那麼可能會有更好的性能明智的擁有單獨的實體，或者可能有6個屬性，我使用謂詞來過濾。？

考慮這個問題時，我意識到，如果我走單獨的實體路線，我允許自己添加因子，只需將它們添加爲實體的實例而不更改我的代碼。

在我寫這篇但希望體驗的核心數據的意見/和數據庫用戶那裏

乾杯

來源

2013-07-30 SimonTheDiver

是它的勸，讓您的實體小我可能已經回答了我的問題。例如，當您有一個列表視圖時，您通常不需要關於對象的所有信息，但是當您單擊一個並轉到詳細信息視圖時，您需要獲取更詳細的信息。然後你可以從其他實體中獲取它。

當然，你應該在這些實體之間建立關係。

來源

2013-07-30 10:57:41 rednaw

那麼，當你獲取一個實體時，所有的屬性都與它一起被填充？ – user523234

是的，它提取整個實體。 – rednaw

我認爲情況有點複雜。核心數據獲取所有屬性值（如果'includesPropertyValues'爲'YES'，則默認爲），並將它們存儲在行緩存中。託管對象將作爲錯誤返回，並且稍後將使用行緩存中的值填充。您可以通過將'returnsObjectsAsFaults'設置爲'NO'來更改此行爲。也就是說，分割你的實體聽起來像個好主意。 –

我不能說這是一個很好的做法，以保持實體「小」與否。但是根據我對核心數據的經驗，大實體不是問題。

大，我的意思是一個具有25到50個屬性的實體，例如很多長字符串或二進制數據。對於該大小的實體，查詢時間通常大於加載和實例化時間。在一次獲取中獲取1000個完整實體通常比獲取1000個部分實體要快，然後錯過100個缺失屬性。

在附註中，我必須在運輸產品中添加我很少使用的那種尺寸的實體。大型實體幾乎總是在幾個較小的相關實體中重構。

現在你告訴你達到了100個屬性。哇。我認爲我從來沒有在我的任何項目中達到過這個標準 - 核心數據或任何「經典」數據庫。我會說這裏的第一個問題是可讀性&可維護性。我很肯定你可以重構一個小實體的大實體，定義定義主體實體的核心屬性，在這裏或那裏找到一些共享的值等等。這肯定會有幫助。

與往常一樣，性能上的明智之處在於，剖析器能準確測量時間花在哪裏。根據我的經驗，提取太多會發生，但提取太少（也就是大量查詢）。

來源

2013-07-31 21:40:29

核心數據性能是否更好，屬性更少？

回答

相關問題