Xcode 防止核心数据将实体合并到一个表中

有没有一种方法可以告诉核心数据，当所有实体都从一个基本实体继承时，不要将它们放在一个表中？这里有一个例子：我们有一个“实体”对象，我们有一个从“实体”继承的“人”和“产品”。核心数据创建一个Zenity表，其中包含“实体”、“人员”和“产品”的组合字段。我们希望核心数据创建两个单独的表，一个用于“个人”，另一个用于“产品”

这可能吗？网上什么都没说

网上什么都没说 这个

这是因为表与核心数据无关

核心数据不是SQL。实体不是表。对象不是行。列不是属性。核心数据是一个对象图管理系统，它可以持久化对象图，也可以不持久化对象图，还可以在后台使用SQL来持久化对象图。试图用SQL术语来理解核心数据会导致您完全误解核心数据，并导致很多悲伤和浪费时间

在这种情况下，经过SQL培训的如何优化SQL的直觉将导致浪费大量时间。如果您在开发过程中进入SQLite存储的峰值，则表明您使用的核心数据不正确。它不仅仅是SQL的对象包装器

当核心数据使用SQLite存储时，将具有相同继承的所有实体放入相同的SQL表是一个设计决策。然而，在大多数情况下，这几乎没有什么功能相关性，因为核心数据首先管理对象图，而不关心持久性的细节。如果同一实体继承树中有大量对象，那么在高端可能会遇到一些性能问题，例如20k+对象，但在其他方面不会

无论如何，这是无法改变的。核心数据故意隐藏了它的SQL实现，因为SQL只是众多持久性选项中的一个

---

过早优化是万恶之源。以逻辑上最好的方式构建，然后进行测试。只有在测试中遇到边缘情况时，才应该担心SQL存储的细节。

我做了测量，在实际（约50000个对象，20多个类，每个都有5个关系，大多数是对多个）数据上使用继承时，CoreData的性能会完全下降。我不会将CD用于1000个对象的玩具应用程序——这是一个真正巨大的应用程序，性能惩罚是不合理的。更糟糕的是，由于这种愚蠢的实现，创建小对象会占用大量ssd和内存空间

唯一真正的解决方案（我确实需要继承）是使用iOS5及更高版本的NSIncrementalStore手动实现替换默认的sqlite持久存储。然而，获取对SQL转换和模型更新的请求确实很难实现

是的，我知道核心数据不是SQL。但我希望在处理大量数据时，它的工作速度相当快，否则在现实世界的应用程序中使用它将是愚蠢的。

根据，解决方案是在模型代码中使用继承，而不是在模式中使用继承：

实体层次结构与类层次结构

托管对象模型提供了创建实体的可能性 层次结构，即我们可以将一个实体指定为另一个实体的父实体 实体。例如，如果我们的实体共享一些 共同属性。然而，在实践中，这很少是你想要的 想做什么

幕后发生的是核心数据存储所有实体 在同一个表中具有相同的父实体。这很快就会造成 具有大量属性的表，降低了性能。 通常，创建实体层次结构的目的仅仅是创建 类层次结构，以便我们可以在多个 将实体添加到基类中。有一个更好的方法来实现 但这是事实

实体层次结构独立于NSManagedObject子类 等级制度或者换句话说，我们不需要有等级制度 在实体中创建类层次结构

---

这似乎是个老问题，但我仍然希望我能帮助其他有同样问题的人

我从这个URL找到了一个很好的答案：

为了避免url在将来失效，我在这里发布了一些重要内容：

例如，我们有从BaseEntity继承的作者和书籍。 我们应该做的是按原样设计实体，而不是使用继承

Entity hierarchy            Class hierarchy
----------------            ---------------
 Authors  Books               BaseEntity
                               |      |
                            Authors  Books

代码应如下所示：

@interface BaseEntity : NSManagedObject
    @property (nonatomic) int64_t identifier;
    @property (nonatomic, strong) NSDate *createdAt;
    @property (nonatomic, strong) NSDate *changedAt;
@end

@interface Author : BaseEntity
    // Author specific code...
@end

@interface Book : BaseEntity
   // Book specific code...
@end

---

在我们的例子中，性能受到严重影响，因此底层实现非常重要，而在所有对象都进入一个表的情况下，性能非常差。这就是黑盒对象映射解决方案的效果。大多数情况下都能正常工作，如果不能正常工作，则很难处理…@Sulthan——核心数据不是SQL包装器，除非进行压力测试，否则您不知道总体性能如何。根据我的经验，大多数关于核心数据SQL性能的担忧都是毫无根据的。除了SQL查找之外，还有很多事情要做。核心数据管理的是整个模型层，而查找只是模型层的一部分。@Sulthan——您使用SQL开发的直觉无法很好地处理核心数据。SQL只是核心数据的一个选项，是最近才添加的。它不是核心数据功能的核心。核心数据主要是一个对象图管理系统，具有多种可选格式的可选持久性。它的主要功能是创建模型层，而不管是否有数据被持久化。@TechZen-核心数据是许多开发人员用来管理持久化数据的工具，包括建模和存储/持久化。它的主要功能是适应那个用例。我不认为所有挥手说“这不是真的要这么做”是合适的。不管它的用途是什么，人们都是这样使用它的。如果我