就目前而言，这个问题不适合我们的问答形式。我们希望答案得到事实、参考资料或专业知识的支持，但这个问题可能会引发辩论、争论、投票或扩展讨论。如果您认为此问题可以改进并可能重新打开，请访问帮助中心获取指导。 10年前关闭。
我已经非常熟悉关系数据库并且过去使用过 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（直接或通过 Objective-C 包装器之一，例如 FMDB）或关系数据库服务器。但是，您可能仍想学习 Core Data 以用作对象图管理框架。结合 Apple 的控制器类和键值绑定兼容的视图小部件，您可以用非常 少的代码实现完整的 MVC 架构。
在 iOS 5.0 中，如果您使用 Core Data，您还可以获得免费使用 iCloud 文件同步的额外好处。如果您直接使用 SQLite，则必须进行大量手动修改和实施才能使其在 iCloud 上同步。
Core Data 与其说是一个数据库引擎，不如说它是一个对实际数据存储进行抽象的 API。您可以告诉 Core Data 保存为 sqlite 数据库、plist、二进制文件，甚至是自定义数据存储类型。
我建议学习 Core Data，因为它是一个极好的资源，可以极大地加速可可应用程序开发的许多部分。
SQLite 是 Core Data 的数据库格式之一。使用 Core Data，您可以更好地与 Cocoa API 的其余部分集成。
关注公众号
不定期副业成功案例分享
