在决定使用哪种持久性时，重要的是要记住，核心数据首先是对象图管理系统。真正的功能是创建Model-View-
Controller设计模式应用程序的运行时模型层。持久性实际上是核心数据的辅助功能，甚至是可选功能。

主要的建模/持久性问题是数据的大小和数据的复杂性。因此，每种持久性的相对优势和劣势将分解如下：

    _______________________________
    |               |              |
  2 |               |              |
    |  SQL          |  Core Data   | 4
s   |               |              |
i   |_______________ ______________|
z   |               |              |
e   |               |              |
  1 |  Collection   |  Core Data   | 3
    |  plist/xml    |              |
    |               |              |
    -------------------------------  
              Complexity--->

我们可以在其中添加第三个出租人维度，即波动性，即数据更改的频率

（1）如果数据的大小，复杂性和易变性低，那么使用序列化自定义对象的集合（例如NSArray，NSDictionary，NSSet）将是最佳选择。必须将集合完全读取到内存中，以限制其有效持久性大小。它们没有复杂性管理，所有更改都需要重写整个持久性文件。

（2）如果大小很大但复杂度很低，则SQL或其他数据库API可以提供出色的性能。例如，旧的时尚图书馆索引卡系统。每个卡都是相同的，卡之间没有关系，卡也没有行为。SQL或其他过程数据库非常擅长处理大量低复杂度的信息。如果数据很简单，那么SQL甚至可以有效地处理易失性数据。如果UI同样简单，那么将UI集成到iOS
/ MacOS应用程序的面向对象设计中的开销很少。

（3）随着数据变得越来越复杂，核心数据迅速变得更加优越。“托管对象”的“托管”部分管理关系和行为的复杂性。使用集合或SQL，您可以手动管理复杂性，并且很快就会陷入困境。实际上，我已经看到有人尝试使用SQL管理复杂数据，但最终他们编写了自己的微型Core
Data堆栈。不用说，将复杂性与波动性结合起来，Core Data会更好，因为它可以自动处理插入和删除的副作用。

（接口的复杂性也是一个问题。SQL可以处理大型的静态单一表，但是当您添加可以随时更改的表层次结构时，SQL会成为噩梦。不重要的。）

（4）Core
Data具有很高的复杂性和规模，显然是上乘的选择。核心数据经过高度优化，因此增加图形大小不会像使用SQL那样使事情陷入困境。您还将获得高度智能的缓存。

另外，不要混淆“我完全理解SQL，但不了解Core Data”和“ Core Data具有高开销”。确实没有。即使Core
Data并不是获取持久性数据的最便宜方法，但如果考虑到开发速度和可靠性，它与API其余部分的集成通常也会产生出色的结果。

在这种特殊情况下，我无法从描述中得知您是案例（2）还是案例（4）。它取决于数据的内部复杂性和UI的复杂性。你说：

我不认为我想创建一个包含100个实体的Core Data模型，然后使用映射器将JSON导入其中。

您是在这里指的是实际的抽象实体还是仅仅是托管对象？请记住，实体对托管对象而言，类对实例而言。如果是前者，那么是的，Core
Data将需要大量工作，如果是后者，则不会。您可以仅使用两个或三个相关实体来构建非常大的复杂图。

还要记住，即使在运行时它们都共享一个上下文，也可以使用配置将不同的实体放入不同的存储中。这可以让您将临时信息放入一个存储中，像更持久的数据一样使用它，然后在完成存储后将其删除。

核心数据为您提供的选择比乍看之下要多。