Core data 对核心数据的担忧

我正准备开始我的第一次核心数据冒险。在评估框架时，出现了两个问题，这两个问题真正让我考虑在这个项目中使用核心数据，或者坚持使用SQLite

我的应用程序将严重依赖于从外部源导入数据。我知道可以导入核心数据，但处理复杂的关系似乎既复杂又乏味。有没有一种简单的方法来完成复杂的导入

应用程序必须能够执行跨越多个表或具有多个条件的复杂查询。构建这些谓词和表达式简直让我害怕

---

是否值得冒险使用核心数据，还是我应该坚持使用SQLite？

我无法回答您的第一点

然而，关于第二点，使用核心数据意味着您不必真正担心复杂的查询，因为您可以假装所有关系都已在内存中正确建立（苹果的实现细节除外）。连接在数据库环境中可能有多复杂并不重要，因为您实际上不在数据库环境中。如果您需要获取当前对象的祖父母的第四个孩子，然后查找该孩子的宠物的名称和品种，那么您所要做的就是使用一系列消息或属性在代码中遍历对象树。不用担心加入或任何事情。唯一的问题是，它可能会非常慢，这取决于对象的关系，但我不能准确地说出来，因为我没有使用核心数据实现任何东西（我只是在苹果和其他公司的网站上广泛阅读了相关内容）。

正如我之前所说，核心数据实际上是一个对象图管理框架。它管理模型对象之间的关系，包括对其基数的约束，并管理级联删除等。它还管理对单个属性的约束。核心数据恰好也能够将对象图持久化到磁盘。它可以以多种格式实现这一点，包括XML、二进制和通过SQLite。因此，核心数据实际上与SQLite正交。如果您的任务是处理嵌入式SQL兼容数据库，请使用SQLite。如果您的任务是管理MVC应用程序的模型层，请使用核心数据。在对您的问题的具体回答中：

没有魔法可以自动将复杂数据导入任何模型。也就是说，在核心数据方面相对容易。使用SQLite后端可以帮助减少内存消耗，因为它允许您一次只在内存中保留数据的一个子集。如果数据集可以保存在内存中，则可以编写自定义持久存储格式，从核心数据中直接读取/写入遗留数据格式（请参阅）

以声明方式构建复杂的

NSPredicate

有点冗长，但不应该吓到您。这是一个很好的开始。当然，您也可以使用字符串格式编写谓词，非常类似于字符串格式的SQL语句。值得注意的是，如上所述，核心数据中的谓词位于对象和对象图上，而不是SQL表上。如果您真的想在表的层次上思考，请坚持使用SQLite并编写自己的包装器

---

如果来自外部源的数据导入器是基于相同的核心数据模型（对于导入的目标/目标端）编写的，那么与使用/更新相同的数据（通过实际应用程序的核心数据堆栈）相比，在概念上没有什么不同

如果您在不使用核心数据堆栈的情况下创建数据导入器，请确保您很好地了解了基于核心数据的模型将生成/预期的db模式。这里没有什么神奇之处——只要确保遵循跨实体关系的实现方式和实体层次结构的存储方式即可

---

我最近不得不创建一个数据导入器，将Access数据库作为.NET应用程序导入到基于核心数据的Sqlite存储中。定义了目标核心数据模型后，我创建了一个小应用程序，用随机生成的实体（包括所有预期的关系）填充Sqlite存储。然后，我反向设计了核心数据实际上如何为模型创建Sqlite存储，以及它如何通过从生成的和持久化的数据中学习来处理关系。然后，根据我的观察，我实现了基于.NET的导入器/数据转换器。最后，我得到了完美的核心数据友好型数据存储，可以从MacOSX上使用核心数据堆栈的应用程序中打开一个修改后的数据存储

我知道这个问题有点老了，但你是如何解决你的第一点的？我有一个非常类似的场景，如果能听到您的解决方案，那将非常高兴。谢谢