我已经相当熟悉关系数据库，并在过去使用
SQLite(和其他数据库)。然而，
Core Data有一定的魅力，所以我正在考虑花一些时间来学习它，用于我的下一个应用程序。
使用Core Data over sqlite有很多好处，反之亦然吗？每个人的利弊是什么？
我觉得很难证明学习Core Data的成本是合理的，当苹果不使用它的许多旗舰应用程序，如Mail.app或iPhoto.app – 而不是选择sqlite数据库。 sqlite也广泛用于iPhone。
那些熟悉使用这两个评论的人的经验？也许，和大多数事情一样，这个问题比只使用一个更深？
虽然Core Data是Apple的
Enterprise Object Framework的后代，但是一个对象关系映射器(ORM)紧密地绑定到一个关系后端，Core Data不是一个ORM。事实上，它是一个对象图管理框架。它管理一个可能非常大的对象实例图，允许应用程序使用一个图形，它不会完全适合内存，如果有必要，通过在内存中断开对象。核心数据还管理关于属性和关系的约束以及维护引用完整性(例如，当向关系添加/移除对象时，保持向前和向后链接一致)。核心数据因此是构建MVC架构的“模型”组件的理想框架。
原文链接：https://www.f2er.com/sqlite/198551.html为了实现其图形管理，Core Data恰好使用sqlite作为磁盘存储。它可以使用不同的关系数据库或甚至非关系数据库(如CouchDB)实现。正如其他人所指出的，Core Data还可以使用XML或二进制格式或用户编写的原子格式作为后端(尽管这些选项要求整个对象图适合内存)。如果你对如何在sqlite后端实现核心数据感兴趣，你可能想检查OmniGroup的OmniDataObjects框架，一个Core Data API子集的开源实现。 BaseTen框架也是使用Postgresql作为后端的Core Data API的实现。
因为Core Data不打算成为sqlite的ORM，所以它不能读取任意的sqlite模式。相反，你不应该依赖于使用其他sqlite工具读取Core Data的sqlite数据存储;该模式是可能更改的实施详细信息。
因此，直接使用Core Data或sqlite之间没有任何冲突。如果您想要关系数据库，请使用sqlite(直接或通过一个Objective-C包装器，如FMDB)或关系数据库服务器。但是，您可能仍需要了解Core Data以用作对象图管理框架。结合Apple的控制器类和键值绑定兼容的视图小部件，您可以用非常少的代码实现一个完整的MVC架构。
