对核心数据的担忧

Posted 2023-03-04

【中文标题】对核心数据的担忧

【英文标题】：Concerns about Core Data

【发布时间】：2009-05-20 18:20:42

【问题描述】：

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

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

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

值得冒险使用 Core Data 还是我应该坚持使用 SQLite？

【问题讨论】：

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

【参考方案1】：

正如I 和others 之前所说，Core Data 确实是一个对象图管理框架。它管理模型对象之间的关系，包括对其基数的约束，并管理级联删除等。它还管理对单个属性的约束。 Core Data 只是碰巧 也能够将该对象图持久化到磁盘。它可以以多种格式执行此操作，包括 XML、二进制和通过 SQLite。因此，Core Data 确实与 SQLite 正交。如果您的任务是处理嵌入式 SQL 兼容数据库，请使用 SQLite。如果您的任务是管理 MVC 应用程序的模型层，请使用 Core Data。具体回答您的问题：

没有魔法可以自动将复杂数据导入任何模型。也就是说，在 Core Data 中相对容易。使用multi-passapproach 并使用 SQLite 后端可以帮助您减少内存消耗，因为它允许您一次只将一部分数据保留在内存中。如果数据集可以保存在内存中，您可以编写自定义持久存储格式，从 Core Data 中直接读取/写入您的旧数据格式（请参阅Atomic Store Programming Guide）。

以声明方式构建复杂的NSPredicate 有点冗长，但不应该吓到你。 Predicate Programming Guide 是一个很好的起点。当然，您也可以使用字符串格式编写谓词，就像字符串格式的 SQL 语句一样。值得注意的是，如上所述，Core Data 中的谓词是在对象和对象图上，而不是在 SQL 表上。如果您真的想从表的层面思考，请坚持使用 SQLite 并编写自己的包装器。

【参考方案2】：

我真的不能说你的第一点。

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

【参考方案3】：

如果来自外部源的数据导入器是基于相同的核心数据模型（对于导入的目标/目标端）编写的 - 与使用/更新相同数据（通过核心来自您的实际应用程序的数据堆栈）。

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

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