核心数据 VS Sqlite 或 FMDB....？

Question

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

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

Answer 1

Ankit，

这是 tl;dr skinny：使用 Core Data。

这是长格式：

虽然您可以使用许多标准在 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，用它来获得性能。 （是的，我知道这与我上面提到的可移植业务逻辑明显矛盾。但实际上，从桌面或服务器环境移植的代码对磁盘速度、内存量和实际情况有很多隐含的假设。带有后备存储的 VM，它在电池供电、内存有限且内存模型很时髦的设备上无法正常工作。[它在 Android 设备上也不能很好地工作。]）您还将对数据进行非规范化以简化在各种 iOS 和 Mac OS X UI 小部件中显示它。有一些应用程序的 Core Data 会比等效的 SQLite DB 慢。这些已在别处详述。一个主要的主张是，由上游数据库定义 ID 的任务会影响 Core Data 的性能是正确的。但明智的索引和过度获取可以在一定程度上缓解这种情况。

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

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

安德鲁

Answer 2

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

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

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

---

TL;DR:

• 请勿使用原始 sqlite3，除非您正在做一些极其微不足道的事情。
• Core Data 适用于仅适用于 iOS 的简单数据，如果您愿意被锁定在其中。
• 如果您想要完全控制数据库并且您不是在做一些微不足道的事情，或者您正在为多个平台构建应用程序，那么 FMDB 绝对是您的最佳选择。

Answer 3

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

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

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

Answer 4

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

一如既往：这真的取决于您的用例。但在 99% 的情况下，CoreData 是正确的选择。

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

Answer 5

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

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

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

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

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

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

Answer 6

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

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