即使只使用一个持久存储，使用不同的CoreData配置来提高性能/减少存储是否有意义？

Question

我正在开发一套应用程序，这些应用程序将有许多相同的模型代码。我正在使用CoreData，所以我目前计划只为所有不同的应用程序创建一个模型文件，尽管并不是所有的应用程序都使用模型中定义的所有实体。

我读过一些关于核心数据配置的文章，这些配置可以在托管对象模型中定义，只得到所有实体的一个子集。我想知道我是否也可以使用这些来优化我的应用程序中的CoreData使用。

考虑以下情况：

我有三个应用程序，App1，App2和App3。它们有一个具有以下实体的共享托管对象模型。

A，A1，A2，A3，B，C，D

而A是抽象的，A1、A2和A3都是从A继承的，每个A1、A2和A3实体都有大约10-20个属性/关系。

现在

• App1只使用A，A1，B，C，D
• App2只使用A，A2，B，C，D
• App3只使用A，A3，B

我读过(不记得在哪里)，为了在sqlite中建模子实体，CoreData只是为父实体创建了一个表，其中包含了作为表列的子实体的所有属性和关系。因此，创建具有多个大型子实体的小父实体通常是不可取的，因为它将导致每个子实体(不需要其他子实体的属性需要列)的大量空列。

现在，使用配置，我可以创建三种配置: Conf1、Conf2、Conf3：

• Conf1包含实体A，A1，B，C，D，
• Conf2包含实体A，A2，B，C，D，
• Conf3包含实体A、A3、B

每个应用程序都会使用具有适当配置的单一存储，因此我不会使用“将对象自动存储在正确的存储区”的优点配置。

然而，我希望通过为每个应用程序中的特定配置添加一个存储库，存储将忽略未包含实体的属性，从而不会创建适当的表列。对于App3/Conf3 3，它甚至可以完全避免为实体C和D创建表。

我的问题是:它是这样工作的吗？是否会将多余的列排除在使用正确配置的持久性存储中？

如果是这样的话:它是否确实对性能或存储需求产生了影响(假设有许多对象，那么性能优化实际上就开始有意义了)？

Answer 1

核心数据是如何表示SQLite存储中的子实体的，这是一个对您隐藏并可能发生更改的实现细节。不要单靠它的工作方式，因为在某一时刻，它的工作方式可能完全不同。

您可能过早地进行了优化。构建它，测试它，如果有一个性能问题产生于您如何使用实体在这一点上解决它。

至于您实际存在的更广泛的问题--对于单个存储使用多个配置是否应该具有性能优势:不应该存在。如果您有一个SQLite存储，并且只有一个配置，那么Core将不会基于(单一)配置进行额外的优化。

Core数据的许多性能来自您的数据模型设计和访问模式。如果应用程序在架构上能够意识到使用经过深思熟虑的数据模型的核心数据错误行为，那么它的性能将是相当好的。即使您的数据模型低于最优，如果优化到持久存储的往返(即管理故障、在适当情况下批处理故障、实现正确的查找或创建)，核心数据也可能非常快。

增量存储编程指南包含了关于如何完成故障的非常好的描述。核心数据编程指南对故障进行了更高层次的描述，并讨论了批处理错误、预取以及查找或创建模式。