后见之明是件好事。
由于人们仍然在阅读这个Q& A并在他们的问题中提到它并认为没有任何变化,我想补充一些评论以澄清并提供“现代”或更近期的回应。
核心数据是一个强大的野兽,但你必须学会控制野兽,并且感谢先前已经回答过的先驱者以及Apple对框架所做的改进,今天做起来比做几个更容易。几年前(特别是iOS 5)。
最初,我建议学习如何准备一个可靠而强大的数据模型。有大量的信息,所以我会留给读者调查。如前面的答案所述,学习准备数据模型中的所有关系非常重要。
除此之外,还有许多机制可以控制您获取的数据集的大小。对于我来说,并没有比Marcus S. Zarra撰写的“核心数据,第2版,iOS,OS X和iCloud的数据存储和管理”(2013年1月)以及特别是第4章标题为“性能调优”。
阅读。
去年我参与了一个做同样事情的项目,我们将所有内容存储在核心数据中,核心数据中的所有内容都从一个具有一些共同属性的类继承而来。
我们的核心数据记录介于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。现在你有了父类,现在是时候调整子类了。将父类设置为RemoteEntity(在我的示例中)而不是NSManagedObject。然后删除超类中出现的所有属性(在我的示例中,“remote_id”和“remote_update”)。
这是我超级班的一个例子 https://gist.github.com/1121689 。
我希望这会有所帮助,请提示@deathbob指出这一点。