我已经非常熟悉关系数据库并且过去使用过SQLite（和其他数据库）。然而，Core Data有一定的吸引力，所以我正在考虑花一些时间来学习它，以便在我的下一个应用程序中使用它。
在 SQLite 上使用 Core Data 有很多好处，反之亦然？每个的优点/缺点是什么？
当 Apple 不将 Core Data 用于其许多旗舰应用程序（如 Mail.app 或 iPhoto.app）时，我发现很难证明学习 Core Data 的成本是合理的，而是选择了 SQLite 数据库。SQLite 在 iPhone 上也被广泛使用。
熟悉使用这两种方法的人可以评论他们的经验吗？也许，和大多数事情一样，问题比仅仅使用一个比另一个更深？
尽管 Core Data 是 Apple 的Enterprise Object Framework的后代，这是一种与关系后端紧密相关的对象关系映射器 (ORM)，但 Core Data 不是 ORM。事实上，它是一个对象图管理框架。它管理一个可能非常大的对象实例图，允许应用程序通过在必要时对内存中的对象进行故障排除来处理无法完全放入内存的图。Core Data 还管理对属性和关系的约束并维护引用完整性（例如，当对象被添加到关系中/从关系中删除时，保持前向和后向链接的一致性）。因此，Core Data 是构建 MVC 架构的“模型”组件的理想框架。
为了实现其图形管理，Core Data 碰巧 使用 SQLite 作为磁盘存储。它 可以 使用不同的关系数据库甚至非关系数据库（例如CouchDB ）来实现。正如其他人所指出的，Core Data 还可以使用 XML 或二进制格式或用户编写的原子格式作为后端（尽管这些选项要求整个对象图适合内存）。如果您对如何在 SQLite 后端实现 Core Data 感兴趣，您可能需要查看 OmniGroup 的OmniDataObjects框架，它是 Core Data API 子集的开源实现。BaseTen框架也是使用 PostgreSQL 作为后端的 Core Data API 的实现。
因为 Core Data 不打算成为 SQLite 的 ORM，所以它不能读取任意 SQLite 模式。相反，您不应该依赖能够使用其他 SQLite 工具读取 Core Data 的 SQLite 数据存储；架构是一个可能会改变的实现细节。
因此，直接使用 Core Data 或 SQLite 之间并没有任何冲突。如果您想要一个关系数据库，请使用 SQLite（直接或通过诸如FMDB之类的 Objective-C 包装器之一）或关系数据库服务器。但是，您可能仍想学习 Core Data 以用作对象图管理框架。结合 Apple 的控制器类和键值绑定兼容的视图小部件，您可以用很少的代码实现完整的 MVC 架构 。
