我正在創建一個與核心數據一起工作的框架。在您的Core Data類上使用我的框架的要求之一是，您希望具有框架功能的任何實體都需要是我提供給您的實體的子實體和子類。爲了這個，我會把這個對象叫做Foo。單核實體核心數據性能
今天我意識到Core Data將所有屬於Foo的子實體的對象存儲到名爲ZFOO的表中。如果有大量數據集的人想要使用它，我擔心Core Data的性能，因爲foo類的所有子實體都將存儲在一個巨大的ZFOO表中。
任何意見或建議將不勝感激。
去年我做了一個做同樣事情的項目，我們將所有內容都存儲在覈心數據中，並將所有內容都存儲在具有一些共同屬性的單個類中繼承的核心數據中。
我們在覈心數據和性能降低到1k-10k之間的某個地方降低了重寫它的次數，並刪除了共同的祖先。我記得簡單的搜索需要幾秒鐘，插入/更新也很蹩腳。只是在事情變得非常緩慢之後，我們纔打開數據庫並在封面下發現核心數據將所有內容都存儲在一張表中。
對不起，我不記得具體的數字，大的外賣是我們不得不重做它，因爲它太慢了，不要太慢，像高頻交易太慢，但太慢，像應用程序在嘗試時崩潰負載從核心數據中填充初始視圖。
因此，用舊的iOS和更舊的硬件的鹽粒，我肯定不會這樣做。
我在這個項目上使用@deathbob作爲iOS領導。在我們的例子中，我有多個包含屬性「remote_id」和「remote_update」的類。我最初使用子類設置表。我有一個「RemoteEntity」抽象實體，它包含這些屬性和一系列從它繼承的其他實體，每個實體都有自己的實體。我想認爲，我們最終會得到一堆表，每個表都帶有remote_id，remote_update，然後是它們的自定義屬性。相反，我們結束了你描述的大量表格。
該修復非常簡單，您必須必須不通過GUI設置繼承。而應該包括該對象的所有屬性，包括你在Core Data建模器中共享的屬性（這意味着「remote_id」和「remote_update」將出現在每個實體中。父類實體的類，這個必須是而不是在GUI中它應該繼承自NSManagedObject，在.m文件中屬性應該使用@dynamic而不是@synthesize現在你有父類了，現在是時候調整（在我的示例中）代替NSManagedObject，然後刪除出現在你的超類（在我的例子中，「remote_id」和「remote_update」）的任何屬性
這裏是一個例子我的超級班https://gist.github.com/1121689。
我希望這可以幫助，帽子提示@deathbob指出這一點。
我有同樣的問題（單親實體，可怕的表現），並想知道是否有像你所描述的方法工作。你如何處理與父實體的關係？ – edsko
謝謝！它工作完美！這樣你就有一個代碼接口，BD中有很多表格（因爲它應該是這樣） –
這聽起來像是一件應該做的事情，也應該拋棄gui。所以這可能是一個錯誤！你還是這樣做還是做了一些改變？ –
事後看來是一件美妙的事情。由於人們仍然在閱讀本文中提到的問題並認爲沒有任何改變，爲了清楚起見，我想添加一些評論，並提供「現代」或更近期的迴應。
核心數據是一個強大的野獸，但您必須學會控制野獸，並感謝先前回答過的先驅以及Apple對框架所做的改進，今天做起來要容易得多幾年前（特別是iOS 5）。
最初我會推薦學習如何準備一個堅實而健壯的數據模型。這裏有大量的信息，所以我會留給讀者去調查。正如前面的答案所提到的，學習準備數據模型中的所有關係非常重要。
除此之外，還有許多機制可以控制您獲取的數據集的大小。對於我來說，這比在實用書架 - Marcus S. Zarra的「核心數據，第二版，適用於iOS，OS X和iCloud的數據存儲和管理」（2013年1月）中的一本書中，第4章標題爲「性能調優」。
閱讀。
你能指出iOS 8+（Xcode 6+）中的一些更新嗎？ – thesummersign
我會更新答案 – andrewbuilder
呀，子類是一般壞CoreData，如果你有大量的數據集，因爲你可以用很解析表中結束。不過，我的建議是先行先試...編寫一個簡單的應用程序，創建Foo類的許多不同子類的數千個對象，並查看系統的行爲方式，如果它不明顯，那麼也許你很好，在做出有關速度的假設之前，始終進行測試 –
尋求建議，我更多地尋找恐怖故事非常錯誤。我讀得越多，Apple似乎實際上鼓勵了Core Data中的這種繼承。 – cruffenach
我可以確認它仍然在Xcode 5 DP5中執行此操作。 – sudo