2

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

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

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

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

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

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

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

4

1 回答 1

2

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 有一个复杂的故障系统，可以在很大程度上解决处理大型数据集时的内存占用问题。
于 2013-04-09T23:32:10.907 回答