36

现在这可能看起来像一个重复的线程，但我的问题是我已经阅读了很多问题，比如...... Core Data vs SQLite 3和其他，但这些都是 2-3 岁。我还读到 FMDB 是由于 iOS 不支持核心数据而开发的，因此不应再使用它。另一方面，我读到不应将核心数据用作数据库。

所以我很困惑，是否应该使用核心数据进行对象存储。我的意思是我应该在什么基础上决定使用哪个？苹果或其他人是否提供了任何指导方针......或者它会随着时间的推移而出现在我身上。？

4

6 回答 6

45

安基特，

这是 tl;dr skinny：使用核心数据。

这是长格式：

虽然您可以使用许多标准在 Core Data、ORM (FMDB) 或直接 sqlite 调用之间进行选择，但这种选择的真正成本来自您使用它的时间、Apple 的支持和其他项目的影响。（将 REST 服务映射到 Core Data 的 RESTKit 现在很流行。）

因此，大部分时间，比如 90+%（一个虚构的统计数据），iOS 上的答案将是使用 Core Data。为什么？一旦你掌握了窍门并构建了一些小辅助方法，Core Data 就会让你进入一个一致的计算世界——Objective-C 对象图。Core Data 将教你如何使用动态语言，这将有助于你的 iOS 编程的各个方面。因此，您的工作效率更高。不要与框架抗争。

如果您从另一个应用程序引入一个大型、复杂的 SQLite 数据库和架构，那么使用 FMDB 或 SQLite 可能具有成本效益。但我对此表示怀疑。您编写基于 Mac 的简单命令行应用程序以将数据库迁移到 Core Data 数据库的时间是一项有限且简单的任务。几乎可以保证您必须重写 Objective-C 中的大部分业务逻辑。（是的，C++ 和 Objective-C++ 都是很好的技术。你的数据库业务逻辑真的被调整为在内存有限的设备上工作吗？我不这么认为。）

Core Data 在性能上受到了普遍的批评。它真的非常快。您只需要以不同于使用数据库的方式使用它。特别是，您几乎总是从存储中过度获取数据，然后直接在各种集合和数组上使用谓词对其进行细化。在闪存速度非常慢的 iOS 设备上，这种过度获取策略特别有效。你实际上在这些设备上有很多 RAM，用它来获得性能。（是的，我知道这与我上面提到的可移植业务逻辑明显矛盾。但实际上，从桌面或服务器环境移植的代码对磁盘速度、内存量和实际情况有很多隐含的假设。一个带有后备存储的虚拟机，它在电池供电、内存有限且内存模型很时髦的设备上无法正常工作。[它不会' 在 Android 设备上也不能很好地工作。]）您还将对数据进行非规范化，以简化在各种 iOS 和 Mac OS X UI 小部件中的显示。有一些应用程序的 Core Data 会比等效的 SQLite DB 慢。这些已在别处详述。一个主要的主张是，由上游数据库定义 ID 的任务会影响 Core Data 的性能是正确的。但是通过明智的索引和过度获取可以在一定程度上减轻它。

关于移动设备要记住的一点是数据库大小，因为这些是互联网叶子上的移动设备，通常大小适中。因此，性能更容易获得。服务器世界的许多教训可能不适用于这个移动、电池供电的世界。

换句话说，你必须“全力以赴”才能在 iOS/Mac OS X 上使用 Objective-C，你也会从使用 Core Data 中获得一些重要的生产力优势。

安德鲁

于 2012-01-05T00:22:10.087 回答
39

我最近自己开始了这段旅程，并最终尝试了所有三个。这是我学到的：

  • 原始 sqlite3
    • 对数据库的低级、完全访问。没有抽象。非常冗长 - 做非常简单的事情需要大量的代码。
  • 核心数据
    • 非常高级，建立在抽象之上，必须使用 Apple 生成的数据库。对 iCloud 同步和简单的仅限 iOS 的数据管理很有用。直接访问数据库困难且危险，不宜用于跨平台数据库。仍然需要相当多的代码来做简单的事情。
  • 调频数据库
    • 高级，非常抽象友好但不强制。如果您需要，仍然可以完全访问数据库。提供一个NSDictionary结果，每个项目自动类型转换为正确数据类型的可变变体（例如，文本列返回为NSMutableString）。我最终围绕它构建了一个非常简单的包装类来进一步抽象它，所以我有一个带有静态函数的帮助类，比如selectAllFrom:(NSString *)table where:(NSDictionary *)conditions返回一个NSArray对象NSDictionary。能够做类似的事情真是太棒了NSArray *usersNamedJoe = [DBHelper selectAllFrom:@"user" where:@{@"name": @"Joe"}];。

基本上，虽然 Core Data 可能对简单的仅限 iOS 的应用程序有用，但任何对使用跨平台数据库感兴趣的人都应该远离它——Apple 没有兴趣让它变得简单，它表明了这一点。

TL;博士：

  • 不要使用原始 sqlite3，除非你正在做一些非常微不足道的事情。
  • Core Data 适用于简单的 iOS-only 数据，如果你愿意被锁定的话。
  • 如果你想完全控制数据库并且你没有做一些微不足道的事情，或者你正在为多个平台构建你的应用程序，那么 FMDB 绝对是要走的路。
于 2013-04-22T14:26:14.410 回答
9

我将FMDB用于我所有大量使用“ INSERTs”的项目，并且 FMDB 并没有过时。Github 上的最后一次提交是在去年 11 月。如果您使用 SQL，我建议您使用 FMDB。

Core Data 适用于所有项目的 95%，但如果涉及到优化，则只能碰壁。如果您想要 Core Data（OOP，...）的好处，请使用它。如果您有很多使用“ WHERE”用户 Sqlite (FMDB)插入和删除

这篇文章解释了 Core Date vs. Sqlite ( FMDB ) 的关闭和顶级站点

于 2012-01-04T09:47:13.370 回答
6

CoreData不仅仅是SQL 数据库的抽象。CoreData 也是做对象图管理的。CoreData 可以做 FMDB 根本做不到的事情。

与往常一样：这实际上取决于您的用例。但在 99% 的情况下，CoreData 是正确的选择。

如果性能至关重要，您仍然必须了解数据库的工作原理。但是，如果您以正确的方式使用 CoreData，它可以提供这种性能。但是需要一些时间来学习。在 CoreData 中有许多琐碎的事情在 FMDB 中会非常复杂。

于 2012-01-05T09:51:01.313 回答
2

作为一个新的 SQL 人，我将投入两分钱：

在 Core Data 中，您需要输入一些“样板”代码，然后才能真正使用数据库。您的应用至少需要以下其中一项：

  1. 持久存储协调器
  2. 托管对象上下文
  3. 一个托管对象。这与一个实体相关，如果您使用 SQLite 数据库，该实体与一个表相关。

要充分利用该框架，您需要了解这些对象在数据管理中所起的作用。

另一方面，我们有 SQLite，在我看来，它更容易理解。首先，您需要：

  1. 一个数据库
  2. 一个或多个表（取决于您的数据）
  3. SQL 知识 - 一种语法简单的灵活语言（SELECT 查询的功能比您最初认为的要多）
  4. 您的应用程序通过它与 SQLite 通信的对象。
于 2015-10-28T18:44:12.610 回答
0

Core Data 只是 SQLite3 数据库的对象抽象。这意味着您将拥有易于管理标准数据库操作的持久对象。您还可以在事务模式下工作，并通过创建模型在 XCode 中设计您的核心数据数据库结构。

如果您不想手动创建 SQLite3 数据库或持久方法，请使用 Core Data。

于 2012-01-04T08:29:24.373 回答