我正在创建一个应用程序，该应用程序要求通过OData Web服务公开其数据的“脱机”持久性。 OData服务使我可以访问基础数据库的所有表以及所有相关数据库字段(例如ID)。
此外，我已经有了一个可以使用的SQLite数据库架构。
我的问题(已经对此进行了两次翻转)是通过SQLite(使用FMDB)直接通过SQLite将Web服务数据存储在设备上还是利用Core Data更好？
如果我使用Core Data，那么我将失去主键和外键的关系优势，但会获得自动嵌套/填充的NSManagedObjects的优势。我不确定如何最好地重新创建数据对象的关系性质。
如果使用SQLite，则可以直接插入/更新Web服务调用的结果，并自动从现有外键列获取关系。缺点是我可能需要将结果手动封装在POCO对象中。
我的直觉告诉我SQLite，但在任何情况下，社区似乎绝大多数都指向Core Data。如果是核心数据，我如何才能最好地创建和维护对象关系(尤其是当它们是“1->很多”时)
如果有任何令Apple满意的问题，则此应用不会进入应用商店。
最佳答案
核心数据直接建立关系模型。因此，在您的模式中，您可能会说该对象A与对象B有关系，并且该关系是“很多”的。但是，这些关系的工作方式就像普通对象引用一样-您需要将A的每个实例链接到B的所有相关实例，您不能[轻松地或通常地]只是说“A通过外键bID与B关联”，然后让关系处理自己。
如果您有一个SQL持久存储，则实现的方法是每个对象为其表获取一个隐式唯一键。关系被建模为一个额外的列，其中包含外部表中每个链接对象的一个或多个键。
人们倾向于不喜欢核心数据的其他方面:
objectID引用是线程安全的，并且您可以根据需要获取类似的安全字典，而不是实时对象)； 反过来:
从iOS 5开始使用
NSIncrementalStore，这样您就可以运行Core Data查询，并且Core Data存储足够聪明，可以在需要时访问服务器-代码主体不知道数据是本地还是远程并且在声明要查找的内容时无需重复进行操作；