现在这可能看起来像一个重复的线程，但我的问题是，我读了很多问题，如.. Core Data vs SQLite 3和其他人，但这些都是2-3岁。我还读过FMDB是在iOS上不支持核心数据的情况下开发的，因此不应再使用它。另一方面，我已经读过，不应该使用核心数据作为数据库。核心数据VS Sqlite或FMDB ....？
所以我很困惑，我是否应该使用核心数据来存储对象或不是。我的意思是我应该决定使用哪个基础？是否有任何指导方针由苹果或其他人提供？或者它会随着时间的推移而来。
ANKIT关和顶位，
这里的tl;博士瘦：使用核心数据。
这里的长型：
虽然你可以使用许多标准的核心数据，一个ORM（FMDB）或直接sqlite的通话之间进行选择，这种选择的真正的成本来自于你的时间使用它，苹果公司支持和利用其他项目。 （将REST服务映射到核心数据的REST Kit现在很流行）。
因此，很大一部分时间，比如90 +％（一个统计数据），iOS上的答案将用于核心数据。为什么？一旦掌握了它并创建了一些小的帮助器方法，Core Data就会使您保持一致的计算世界 - Objective-C对象图。核心数据将教你如何使用动态语言，这将有助于你的iOS编程的其他方面。因此，你更有成效。不要打架。
如果您从其他应用程序引入大型复杂SQLite数据库&架构，那么使用FMDB或SQLite可能具有成本效益。但我怀疑它。编写简单的基于Mac的命令行应用程序将数据库迁移到核心数据DB的时间是一项有限而简单的任务。您几乎可以保证必须重写Objective-C中的大部分业务逻辑。 （是的，C++和Objective-C++都是很好的技术，你的数据库业务逻辑是否真的被调整用于限制内存的设备上？我不这么认为）。
核心数据在性能上受到了热捧。这真的很快。您只需要使用它与使用数据库不同。特别是，您几乎总是从存储中过度获取数据，然后使用谓词直接在各种集合和数组上进行优化。在iOS设备上，闪存出人意料地很慢，这种超取策略特别有效。你在这些设备上实际上有很多RAM，用它来获得性能。 （是的，我知道这与我上面提到的便携式业务逻辑存在明显的矛盾，但实际上，从桌面或服务器环境移植的代码对于磁盘速度，内存数量和实际情况有着许多隐含的假设一台具有后备存储的虚拟机，在电池供电，内存有限的设备上使用时髦的内存模式，它不能很好地工作[在Android设备上它也不能很好地工作。]）您还可以非规范化数据以简化将其显示在各种iOS和Mac OS X UI小部件中。有一些应用程序的核心数据将比等效的SQLite数据库慢。这些在其他地方已经详述一个主要的主张是，由上游数据库定义ID的任务触及Core Data的性能是真实的。但是可以通过明智的索引和过度提取来缓解。
有关移动设备的事情要记住的一点是，数据库的大小，因为这些是互联网叶子上的移动设备，通常是适度的大小。因此，表现更容易达到。来自服务器世界的许多经验教训可能不适用于这种移动电池供电的世界。
换句话说，您必须全程使用iOS/Mac OS X上的Objective-C，您才能从使用Core Data获得一些重要的生产力优势。
安德鲁
作为目前的维护者Jeff LaMarche的SQLite持久对象，我补充说FMDB是适合使用的SQLite包装。仅仅因为它最近没有更新并不表示放弃，而是成熟。例如，我维护Apple的Reachability代码版本，
核心数据只是SQLite3数据库的对象抽象化。这意味着您将拥有易于管理标准数据库操作的持久对象。您也可以在事务模式下工作，并通过创建模型在XCode中设计核心数据库结构。
如果您不想手动创建SQLite3数据库或持久性方法使用核心数据。
那么我们可以完全排除FMDB吗？ – 2012-01-04 08:57:34
我认为使用FMDB是因为核心数据在iOS中不可用<3.0 – 2012-01-04 09:10:22
核心数据不是数据库：http://cocoawithlove.com/2010/02/differences-between-core-data-and.html。核心数据使用数据库eq Sqlite来存储数据。 – CarlJ 2012-01-04 13:54:34
对于我所有使用“INSERT s”的项目，我使用FMDB，并且FMDB没有过期。 Github上最后一次提交是在去年11月。如果你使用SQL，我建议你使用FMDB。
核心数据适合所有项目的95％，但如果涉及到优化运行到墙上。如果你想要核心数据（OOP，...）的好处，那就使用它。如果你有很多插入一个与“WHERE”用户sqlite的（FMDB）删除
这POST解释核心日期与sqlite的（FMDB）
我不明白为什么要使用包装而不是直接使用Objective-C sqlite3函数。我通常使用Core Data来进行模型设计。 – 2012-01-04 10:06:42
简单：它更易于使用！你不用自己处理sqlite的“锁定”状态，它的线程保存，模式匹配，你可以使用普通的基础对象，你的代码更干净。 （FMDB）6行代码与10 ++代码行与sqlite – CarlJ 2012-01-04 10:19:20
我认为你的代码比Core Data更清晰，最重要的是容易维护（通过逆向工程）。 – 2012-01-04 11:06:06
CoreData是不只是一个SQL数据库的抽象。 CoreData也是对象图管理。 CoreData可以做FMDB根本做不到的事情。
一如既往：这取决于您的使用案例。但在99％的案例中，CoreData是正确的选择。
如果性能至关重要，您仍需了解数据库的工作方式。但是如果您使用正确的方式，CoreData可以提供这种性能。但是需要一些时间来学习。在CoreData中做很多事情是微不足道的，这在FMDB中会非常复杂。
我将通过FMDB并在未来的项目中使用核心数据。谢谢... – 2012-01-05 10:12:09
我最近自己踏上了这段旅程，最终尝试了三种。这是我学到：
NSDictionary，每个项目自动键入适当数据类型的可变变体（例如，文本列的返回形式为NSMutableString）。我最终围绕它构建了一个非常简单的包装类，以更多地抽象它，所以我有一个带有静态函数的帮助类，如selectAllFrom:(NSString *)table where:(NSDictionary *)conditions，它返回NSArray的NSDictionary对象。能够做到像NSArray *usersNamedJoe = [DBHelper selectAllFrom:@"user" where:@{@"name": @"Joe"}];这样的事情真是太棒了。基本上，而核心数据可用于简单的iOS专用的应用程序，任何人谁是热衷于使用跨平台数据库应该留远，远离它是有用的 - 苹果公司在做那么容易没有兴趣，它表明。
TL; DR：
作为一个新的SQL的家伙，我要去把我的0.02：
在核心数据，你有一点的“样板”的代码，你需要把之前你可以真正使用你的数据库。您的应用程序至少需要以下其中一项： 1）持久性商店协调员 2）受管理对象上下文 3）受管理对象。这与一个实体相关，如果您使用SQLite数据库，则该实体与表关联。
要充分利用框架，您需要了解这些对象在管理数据中扮演的角色。
另一方面，我们有SQLite，在我看来，它更容易理解。首先，你需要： 1）一个数据库 2）一个表或更多（取决于你的数据） 3）SQL知识 - 一种灵活的语言与一个简单的语法（SELECT查询做的比你最初的认为他们） 4）一个对象，通过它你的应用程序与SQLite进行通信。
你要存储什么数据，有多少数据，你需要做什么检索，用户可以编辑？ – jrturton 2012-01-04 08:29:16
这就是我的问题所在。我的意思是我应该决定使用哪种方式，并且是否有任何由苹果或其他人提供的指导方针......或者是随着时间的推移而来的东西。 – 2012-01-04 08:31:49
如果您需要一次更新，插入或删除多行，那么Core Data不是一个好选择。 – AechoLiu 2012-01-04 10:23:19