簡體   English   中英

與我的多對多關系,獲取核心數據非常慢?

[英]Core Data fetches are extremely slow with my many-to-many relationships?

我有一個核心數據數據庫,其中包含3種實體類型,單位/部門/文檔。

部門/部門在部門方面有一對多的關系,即一個部門可以有多個部門,但是每個部門只能有一個部門。

每個文檔可以是一個或多個單位和/或部門的一部分,我需要能夠找到與所選單位或部門匹配的文檔。 單位ID可以是“ 1234”,該部門的部門ID可以是“ 123499”。 請注意,部門編號始終是單位的4個數字,然后是另外2個描述部門的數字。

對於數據模型來說太多了,問題是當我選擇一個部門(沒有部門)並且需要列出該部門下的所有文檔時,搜索應該返回屬於該部門的所有文檔以及該部門的所有文檔。屬於該部門下的所有部門,並且搜索需要花費4秒鍾以上的時間來查找5000個文檔,所以我必須做錯什么。

我正在使用NSFetchedResultsController,這是我的謂詞。

NSPredicate *predicate;
NSFetchRequest *req = [NSFetchRequest fetchRequestWithEntityName:@"Document"];   
[req setPropertiesToFetch:[NSArray arrayWithObjects:@"name",@"publisher",@"isFavourite", nil]];
 req.sortDescriptors = [NSArray arrayWithObject:[NSSortDescriptor sortDescriptorWithKey:@"name" ascending:YES]]; 
[req setFetchBatchSize:15];
predicate = [NSPredicate predicateWithFormat:@"ANY units.id == %@ || ANY departments.id BEGINSWITH[cd] %@",self.selectedUnit.id,self.selectedUnit.id];

我可以用其他方式嗎? 我想知道是否可以選擇Unit,然后再通過Unit.documents,但是后來我認為不需要FetchController,我需要將結果放入Array中,然后對它們進行排序(獲取所有實體) ,甚至需要更長的時間。..

更糟糕的是,我還需要稍后能夠在文檔的Name屬性中進行搜索,而CONTAINS [cd]會使搜索更加緩慢,但是很遺憾,我無法將單詞拆分為單獨的表,因為我需要可以在單詞內處理單詞,即用戶可以鍵入“結果”,並且搜索應返回標題中某處具有“結果”的所有文檔,例如“ NSFetchedResultControllers很酷”

我如何才能使CONTAINS搜索的性能更好,現在我只有5000個文檔,但也可能是20000個或更多。

有什么好主意,想法嗎? 我看了很多WWDC核心數據視頻,在Apple開發人員網站上閱讀了核心數據性能,我確實認為我做得對,但是也許我的模型是錯誤的,我可以在SQL調試中看到,在連接表上花了很多時間,我試圖弄清楚如何使該SQL更加整潔。

非常感謝/ Jacob

您認為CONTAINSBEGINSWITH降低了查詢速度,這是正確的。 我有兩個想法給你:

  1. 使用索引(我確信您從WWDC視頻中知道)。 特別是對於使用CONTAINS進行文本搜索而言,這應該會大大提高性能。

  2. 對於您提到的特定謂詞,我將嘗試使用id的number屬性。 在您的方案中,您已經方便地按單位訂購了ID。

謂詞可能是這樣的:

NSNumber *bottom = [NSNumber numberWithInt:[self.selectedUnit.id intValue]*100];
NSNumber *top = [NSNumber numberWithInt:([self.selectedUnit.id intValue]+1)*100];
[NSPredicate predicateWithFormat:
   @"ANY units.id == %@ || ANY (departments.id > %@ AND departments.id < %@)",
   self.selectedUnit.id, bottom, top];

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM