Question

iOS 开发如果涉及数据和表的持久化，Core Data 比 SQLite 更好吗

Answer 1

　　首先，coredata和sqlite的概念不同，core为对象周期管理，而sqlite为dbms。
下面的讨论以使用core data来做数据持久化并使用sqlite做backend存储的情况为前提。

　　使用方便性。实际上，一个成熟的工程中一定是对数据持久化进行了封装的，因此底层使用的到底是core data还是sqlite，不应该被业务逻辑开发者关心。因此，即使习惯写SQL查询的人，也应该避免在业务逻辑中直接编写SQL语句。
　　存储性能，在写入性能上，因为都是使用的sqlite格式作为磁盘存储格式，因此其性能是一样的，如果你觉得用core data写的慢，很可能是你用sqlite的时候写的每条数据的内容没有core data时多，或者是你批量写入的时候每写入一条就调用了一次save。
　　查询性能，core data因为要兼容多种后端格式，因此查询时，其可用的语句比直接使用sqlite少，因此有些fetch实际上不是在sqlite中执行的。但这样未必会降低查询效率。因为iPhone的flash memory速度还是很快的。我的经验是大部分时候，在内存不是很紧张时，直接fetch一个entity的所有数据然后在内存中做filter往往比使用predicate在fetch时过滤更快。如果你觉的查询慢，很可能是查询方式有问题，可以把core data的debug模式打开，看一下到底执行了多少SQL语句，相信其中大部分是可以通过改写core data的调用方式避免的。
　　core data的一个比较大的痛点是多人合作开发的时候，管理coredata的模型需要很小心，尤其是合并的时候，他的data model是XML格式的，手动resolve比较烦心。
　　core data还有其他sql所不具备的优点，比如对undo的支持，多个context实现sketchbook类似的功能。为ManagedObject优化的row cash等。
　　另外core data是支持多线程的，但需要thread confinement的方式实现,使用了多线程之后可以最大化的防止阻塞主线程

Answer 2

　　这两个东西我都用过，两者都能实现对数据库的操作，功能上需求都能满足。
　　先前在公司实习的时候，原先项目中用的是SQLite，感觉操作很直接。如果先前有一点数据库和SQL基础的话，写起来会感觉很亲切，都是一些数据库操作的语句。但是当操作变多之后，语句越来越多，就很烦，代码比较多，看起来也会混乱一些。
　　后来新项目中尝试了CoreData，因为苹果一直在推这个东西。CoreData用起来比直接sql语句方便许多，而且很适合进行代码封装、重构。其实后来在用CoreData的时候，参照RestKit的ObjectMapping和CoreData部分对其进行了少量封装，使得CoreData用起来非常方便。例如：添加一条User数据
　　User *user = [User object];
　　user.name = @"example";
　　[objectStore save];
　　后来做开发一直都在用CoreData，主要是我觉得用起来太方便了，代码能够精简许多。另外，
　　App升级之后数据库字段或者表有更改会导致crash，CoreData的版本管理和数据迁移变得非常有用，手动写sql语句操作还是麻烦一些。
　　CoreData不光能操纵SQLite，CoreData和iCloud的结合也很好，如果有这方面需求的话优先考虑CoreData。
　　CoreData并不是直接操纵数据库，比如：使用CoreData时不能设置数据库的主键，目前仍需要手动操作。
　　效率上其实跑程序时感觉不出来，毕竟手机上的数据不能跟网站的数据和访问量相提并论。

　　总的来说，个人比较喜欢用CoreData，因为自己比较熟悉，使用起来也非常方便。
　　PS：既然你一直在CoreData，就应该坚持用下去，除非是真的碰到很致命的无法解决问题。中途换掉既有的自己熟悉的东西，费时费力，实际用起来没区别，得不偿失。
转载

Answer 3

coredata和sqlite的概念不同，core为对象周期管理，而sqlite为dbms。
1.如果你的项目规模比较大，用coreData 可以减少你对存储管理的很多工作，否则你可能需要自己写很多的数据模型倒数据库操作的代码。
2.你的数据结构变化，数据迁移的时候coreData能帮你自动的完成，用sqlite 你就需要自己写代码来完成。
3.coreData还有些其他效率方面的优化，比如延迟写入。