CoreData - 在實體上有很多關係時的性能

我希望以前沒有問過這個問題，我搜索了一個類似的問題，但找不到與我的案例足夠接近的內容。CoreData - 在實體上有很多關係時的性能

基本上，我的問題是如果CoreData可以處理大量的關係（大，我的意思是可能高達30對某些實體），而不是太慢。

我有這些實體（只是作爲示範）：

Resources (contains all Resources for an object) 
ProcessA 
ProcessB 
ProcessC 
ProcessD 
ProcessE 
... (many more)

所需的各種任務。這些過程，但幾乎所有的人都需要有Resources一個一對一（或者一對多）的關係。

有時，他們甚至需要多個關係到Resources（currentResources和oldResources或其他）。這就是爲什麼我需要添加一個反向關係（如果我沒有反向，它實際上會導致問題，我不知道爲什麼）。

由於逆時，Relationships實體開始是這樣的：

Resources 
    someAttribute 
    ... 
    --- 
-> inverseOfProcessA 
-> inverseOfProcessB 
-> inverseOfProcessC 
-> inverseOfProcessD 
-> inverseOfProcessE 
-> ...

它變得充滿了，我將永遠需要從這個方面來訪問反向關係（他們只需要在那裏阻止一些奇怪的事情發生）。

我讀到faulting的概念。我的理解是正確的，當我獲取一個Resources對象時，它實際上並沒有加載所有關係？如果是這樣，faulting有多高效？因爲它必須填寫所有與fault對象的關係。這是我不確定的部分。當一個實體有很多關係時，這會影響性能嗎？

對不起，如果這是一個微不足道的問題。答案可能是顯而易見的，但我剛開始擔心性能，這讓我感興趣（儘管我在文檔中閱讀了大約faults，但這並不是100％清楚）

來源

2017-10-14 Quantm

其實，如果你問自己Core Data是否會與你的模型發生衝突，你必須問自己，如果你的選擇是好的。我不知道Core Data是否可以處理這個問題，答案可能是肯定的，但它取決於其他各種因素：我們是在談論少數條目還是數以千計的條目？有多少個提取請求？

關於您的模型：爲什麼不創建單個實體使用一種方法區分進程A和進程B（標識符是整數或字符串）？

關於斷裂：默認情況下，當你創建一個NSFetchRequest，returnsObjectsAsFaults設置爲真正讓用戶無需在內存物化的所有對象與大型數據集工作。如果您知道要訪問所有關係，則可以將此屬性設置爲false以便使用完全物化對象，從而爲持久層節省大量往返行程。

請記住，核心數據只是圍繞關係數據庫的包裝，所以請記住這一方面來優化您的模型和您的請求。

來源

2017-10-14 20:33:25 McNight

我以前只是這樣做的（使用一個'Process'就像你說的那樣）。它導致了難看，複雜和難以維護的代碼（在我的情況下，沒有更漂亮的方式）。另外，每個進程都需要具有不同類型的屬性和關係（例如，'ProcessA'需要保存3個字符串和一個Float，而'ProcessB'需要3個整數和一個日期。我需要有許多「通用」屬性（比如'string1'，'string2'，'integer1'，...），這些都很醜陋。我有一個解決方法，但更糟糕。 – Quantm

這就是爲什麼我切換到單目的實體，這導致了非常清晰和易於維護的代碼，並且更容易處理。有人告訴我，一直以來只有一個目標是一個好主意。 – Quantm

我瞭解您的問題，但您必須找到解決方法，因爲即使您持有Resource對象，您如何知道哪個關係指向正確的流程？嘗試添加其他實體以將您的模型分解爲其他片段或使用父實體。 – McNight

CoreData - 在實體上有很多關係時的性能

回答

相關問題