核心数据VS Sqlite或FMDB …？

现在这可能看起来像一个重复的线程，但我的问题是，我已经阅读了很多问题，如核心数据与SQLite 3等，但这些都是2 – 3年。 我也读过FMDB是由于核心数据在iOS上不被支持而开发的，所以不应该再使用它。 另一方面，我已经读过，不应该使用核心数据作为数据库。

所以我很困惑，是否应该使用核心数据来存储对象 。 我的意思是我应该决定使用哪一个？ 有没有任何指导提供的苹果或别人..或者是什么东西，会随着时间的推移。

Answer 1

ANKIT，

这里是tl;博士瘦：使用核心数据。

这是一个长的forms：

虽然你可以使用许多标准来select核心数据，ORM（FMDB）还是直接的sqlite调用，但这个select的实际成本来自你使用它的时间，苹果的支持和其他项目的影响力。 （将REST服务映射到Core Data的REST Kit现在很受欢迎。）

因此，很大一部分时间，比如90 +％（一个统计数据），iOS上的答案就是使用核心数据。 为什么？ 一旦你掌握了它并build立了一些小的帮助器方法，Core Data就让你保持一致的计算世界 – Objective-C对象图。 核心数据将教你如何使用dynamic语言，这将有助于你的iOS编程的其他方面。 因此，你更有成效。 不要打架。

如果您从另一个应用程序中引入大型，复杂的SQLite数据库和模式，那么使用FMDB或SQLite可能会比较划算。 但我怀疑它。 您的时间编写一个简单的基于Mac的命令行应用程序将数据库迁移到核心数据数据库是一项有限而简单的任务。 您几乎可以保证必须重写Objective-C中的大部分业务逻辑。 （是的，C ++和Objective-C ++都是很好的技术，你的数据库业务逻辑是否真的被调整用于内存有限的设备上？我不这么认为）。

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

关于移动设备的事情也要记住的是数据库的大小，因为这些是在互联网上的移动设备，通常是适度的大小。 因此，performance更容易达到。 来自服务器世界的许多教训可能不适用于这个移动电池供电的世界。

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

安德鲁

Answer 2

我最近自己踏上了这个旅程，最终尝试了三个。 以下是我所学到的：

• 原始的sqlite3
  • 低级别，完全访问数据库。 没有抽象。 非常冗长 – 需要很多代码来完成非常简单的事情。
• 核心数据
  • 非常高级的，基于抽象的，必须使用苹果生成的数据库。 用于iCloud同步和简单的仅限iOS的数据pipe理。 直接访问数据库是困难和危险的，不应该用于跨平台的数据库。 仍然需要相当数量的代码来做简单的事情。
• FMDB
  • 高层次，非常抽象友好，但不是强迫。 如果你需要的话，仍然可以完全访问数据库。 提供结果的NSDictionary ，每个项目自动被转换为适当数据types的可变变体（例如，文本列作为NSMutableString返回）。 我最终build立了一个非常简单的包装类来抽象它更多，所以我有一个类似于selectAllFrom:(NSString *)table where:(NSDictionary *)conditions静态函数的助手类selectAllFrom:(NSString *)table where:(NSDictionary *)conditions ，它返回一个NSArray的NSDictionary对象。 能够做NSArray *usersNamedJoe = [DBHelper selectAllFrom:@"user" where:@{@"name": @"Joe"}]; 。

基本上，虽然核心数据对于简单的iOS应用程序可能是有用的，但任何有兴趣使用跨平台数据库的人都应该远离它，苹果没有兴趣去实现这一点。

---

TL; DR：

• 不要使用原生sqlite3，除非你正在做一些非常微不足道的事情。
• 核心数据适用于简单的仅限iOS的数据，如果您对被locking的数据感到满意。
• 如果你想完全控制数据库，而不是做一些微不足道的事情，或者你正在为多个平台构build你的应用程序，那么FMDB肯定是一个很好的select。

Answer 3

我使用FMDB来处理大量使用“ INSERT s”的项目，FMDB不会过期。 Github上最后一次提交是在去年11月。 如果你使用SQL，我build议你使用FMDB。

核心数据适合所有项目的95％，但如果涉及到优化运行到一堵墙。 如果你想要核心数据（OOP，…）的好处，然后使用它。 如果你有很多插入删除与“ WHERE ”用户Sqlite（FMDB）

这篇文章解释了Core Date和Sqlite（FMDB）的closures和顶部站点，

Answer 4

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

一如既往：这取决于你的用例。 但在99％的情况下，CoreData是正确的select。

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

Answer 5

作为一个新的SQL人员，我将会抛出我的.02：

在核心数据中，在使用数据库之前，您需要input一些“样板”代码。 您的应用程序至less需要以下其中一项：1）持久存储协调器2）受pipe对象上下文3）受pipe理对象。 这与一个实体相关，如果您使用SQLite数据库，则该实体与表相关。

要充分利用框架，您需要了解这些对象在数据pipe理中扮演什么angular色。

另一方面，我们有SQLite，在我看来，它更容易理解。 首先，你需要：1）数据库2）一个或多个表（取决于你的数据）3）对SQL的了解 – 一种简单的语法的灵活的语言（SELECT查询做的比你原先想象的要多）4）你的应用程序通过它与SQLite进行通信的对象。

Answer 6

核心数据只是SQLite3数据库的对象抽象化。 这意味着您将拥有易于pipe理标准数据库操作的持久对象。 您也可以在事务模式下工作，并通过创build模型来在XCode中devise核心数据库结构。

如果你不想手动创build你的SQLite3数据库或持久的方法使用核心数据。