Core Data vs. SQLite 用于通过 OData 公开的现有数据库的脱机持久性

Question

我正在创建一个应用程序，该应用程序需要“离线”持久化通过 OData Web 服务公开的数据。 OData 服务让我可以访问底层数据库的所有表，以及所有相关的数据库字段，例如 ID。

此外，我已经有一个可以使用的 SQLite 数据库架构。

我的问题是，我已经问过两次了，是直接通过 SQLite（使用 FMDB）将 Web 服务数据存储在设备上，还是利用 Core Data 更好？

如果我使用 Core Data，那么我将失去主键和外键的关系优势，但会获得自动嵌套/填充的 NSManagedObjects 的优势。我不完全确定如何最好地重新创建我的数据对象的关系性质。

如果我使用 SQLite，我可以直接插入/更新 Web 服务调用的结果，并自动从现有的外键列中获取关系。缺点是我可能需要手动将结果封装在 POCO 对象中。

我现在的直觉告诉我 SQLite，但似乎社区在任何/所有情况下都以压倒性多数指向 Core Data。如果是 Core Data，我如何最好地创建和维护对象关系（尤其是当它们是 1->many 时）

如果任何与 Apple 相关的方面存在问题，此应用将不会进入应用商店。

Answer 1

Core Data 直接对关系建模。因此，在您的架构中，您可能会说例如对象 A 与对象 B 有关系，并且该关系是“对多”的。然而，这些关系就像普通的对象引用一样工作——您需要将 A 的每个实例链接到 B 的所有相关实例，您不会 [容易或通常] 只是说“A 通过外键 bID 与 B 相关”然后让关系自己处理。

如果您有一个 SQL 持久存储，那么实现的方式是每个对象都为其表获取一个隐式唯一键。关系被建模为一个额外的列，其中包含外部表中每个链接对象的一个​​或多个键。

人们往往不喜欢 Core Data 的其他方面：

• 如果您始终依赖于隐式数据获取，那么您通常会获得较差的性能，因此您通常最终会使用显式查询来填充您可能即将在一次数据库访问中查看的结果；
• 由于 SQLite 不是线程安全的并且 Core Data 对象保持与其存储的实时连接，Core Data 对象不是线程安全的（尽管 objectID 对它们的引用是并且您可以获取类似安全的字典而不是实时对象，如果您更喜欢）；
• 即使您以其他方式解决了线程问题，根据 SQLite 线程安全注释，在后台保存仍会阻止前台访问。

反过来：

• 从 iOS 5 开始，您可以使用NSIncrementalStore，这样您只需运行 Core Data 查询，并且您的 Core Data 存储足够智能，可以在需要时访问服务器——您的代码主体不知道数据是否是本地或远程的，在声明要查找的内容时不需要重复；
• 您可以免费获得实时数据库连接，因此如果持久存储发生更改，您的对象会自动更新自己；
• 如果您主要寻找 iPhone 样式的表格视图，那么这项工作几乎已经为您完成，您几乎只需提供查询即可；
• Core Data 具有复杂的故障排除系统，可在很大程度上解决处理大型数据集时的内存占用问题。