ios - Core Data vs. SQLite 用于通过 OData 公开的现有数据库的脱机持久性
<p><p>我正在创建一个应用程序，该应用程序需要对其通过 OData Web 服务公开的数据进行“离线”持久性。 OData 服务让我可以访问底层数据库的所有表，以及所有相关的数据库字段，例如 ID。</p>
<p>另外，我已经有了一个可以使用的 SQLite 数据库架构。</p>
<p><strong>我的问题是，我已经问过两次了，是直接通过 SQLite(使用 FMDB)将 Web 服务数据存储在设备上，还是利用 Core Data 更好？</strong></p>
<p>如果我使用 Core Data，那么我将失去主键和外键的关系优势，但会获得自动嵌套/填充的 NSManagedObjects 的优势。我不完全确定如何最好地重新创建我的数据对象的关系性质。</p>
<p>如果我使用 SQLite，我可以直接插入/更新 Web 服务调用的结果，并自动从现有的外键列中获取关系。缺点是我可能需要手动将结果封装在 POCO 对象中。</p>
<p>我现在的直觉告诉我 SQLite，但似乎社区在任何/所有情况下都绝大多数指向 Core Data。如果是 Core Data，我如何最好地创建和维护对象关系(尤其是当它们是 1->many 时)</p>
<p>如果任何与 Apple 相关的方面存在问题，此应用将不会进入应用商店。</p></p>
<br><hr><h1><strong>Best Answer-推荐答案</ strong></h1><br>
<p><p>Core Data 直接对关系建模。因此，在您的架构中，您可能会说例如对象 A 与对象 B 有关系，并且该关系是“对多”的。然而，这些关系就像普通的对象引用一样工作——您需要将 A 的每个实例链接到 B 的所有相关实例，您不会 [容易或通常] 只是说“A 通过外键 bID 与 B 相关”然后让关系自己处理。</p>
<p>如果您有一个 SQL 持久存储，那么实现的方式是每个对象都为其表获取一个隐式唯一键。关系被建模为一个额外的列，其中包含外部表中每个链接对象的一个或多个键。</p>
<p>人们往往不喜欢 Core Data 的其他方面:</p>
<ul>
<li>如果您始终依赖隐式数据获取，那么您通常会获得较差的性能，因此您通常最终还是会使用显式查询来填充您可能即将在一次数据库访问中查看的结果；</li>
<li>由于 SQLite 不是线程安全的并且 Core Data 对象保持与其存储的实时连接，Core Data 对象不是线程安全的(尽管对它们的 <code>objectID</code> 引用是并且您可以取而代之获取类似安全的字典如果您愿意，可以使用活体)；</li>
<li>即使您以其他方式解决了线程问题，根据 SQLite 线程安全注释，在后台保存仍会阻止前台访问。</li>
</ul>
<p>反之:</p>
<ul>
<li>从 iOS 5 开始，您可以使用 <code>NSIncrementalStore</code>，这样您只需运行 Core Data 查询，并且您的 Core Data 存储足够智能，可以在需要时访问服务器 - 您的代码主体有不知道数据是本地的还是远程的，并且在声明要查找的内容时不需要重复；</li>
<li>您可以免费获得实时数据库连接，因此如果持久存储发生变化，您的对象会自动更新；</li>
<li>如果您主要是做 iPhone 风格的表格 View ，那么这项工作几乎已经为您完成，您几乎只需提供查询即可；</li>
<li>Core Data 具有复杂的故障排除系统，可在很大程度上解决处理大型数据集时的内存占用问题。</li>
</ul></p>
<p style="font-size: 20px;">关于ios - Core Data vs. SQLite 用于通过 OData 公开的现有数据库的脱机持久性，我们在Stack Overflow上找到一个类似的问题：
<a href="https://stackoverflow.com/questions/15914064/" rel="noreferrer noopener nofollow" style="color: red;">
https://stackoverflow.com/questions/15914064/
</a>
</p>
页:
[1]