核心数据sqlite存储单表由于继承的缺点？

Question

我有一个类似20个实体的核心数据模型。我希望所有实体具有共同的属性。例如，它们都具有创建日期属性。 因此，我介绍了一个包含所有常用属性的公共实体，并且所有其他实体都从此公共实体继承。

这很好，但效果很好，但是，所有实体最终都在一个SQLite表中（这很合逻辑）。

我想知道是否有明显的缺点？例如，当每个实体的1000多个对象在现实生活中进行时，（单个）表会变得如此巨大以至于可能发生可怕的性能问题？

Answer 1

这个问题已经被问过：

Core Data entity inheritance --> limitations?

Core data performances: when all entities inherit from the same parent entity

Core Data inheritance vs no inheritance

还铭记保持，当你想检查的SQLite文件进行调试，独立的表是更容易检查。

我会使用一个通用的NSManagedObject子类而不是父实体。

Answer 2

不要担心这一点。从核心数据文档：

https://developer.apple.com/library/tvos/documentation/Cocoa/Conceptual/CoreData/Performance.html

... SQLite的存储可以扩展到TB级数据库与数十亿行，表和列。除非您的实体本身具有非常大的属性或大量的属性，否则10,000个对象对于数据集而言被认为是相当小的尺寸。

什么方式更重要的是，如果你正在做的任何重的操作，比如获取大量的对象，或分析基于从Web服务的一些JSON对象，你就mainthread做到这一点不。这不是很难做到，查看父/子managedobjectcontexts以及如何将它们与private/main队列并发类型一起用于managedcontextobjects。许多关于这个主题的好博客文章都存在于互联网上。

Answer 3

我一直在为一个项目开发一个基本实体，其中包含大约20个子实体，并且现在已经有超过2年的整个50k实例。我们从来没有选择，插入或更新的性能问题。

使用核心数据继承大型数据集的键是

• 优化提取请求（乐曲谓词，排除不相关的特性，预取的关系，省略子实体，设置fetchLimit，使用词典结果类型或计数的请求如果足够等）
• 批量保存（意味着每次插入后不保存MOC等））
• 建立适当的索引（它们可以加快选择looot）
• 适当地组织你的UI，所以你就不必加载和一个显示几千对象的viewController

我们甚至不因为我们的数据模型和映射代码是如此高度优化的，所以在导入JSON时，使用父/子managedObjectContexts或私有队列（自己引入了很多额外的复杂性），导致UI甚至不会闪烁或挂起几千个物体。