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

我一直用coreData解决, 我觉得这样效率高,再说coredata也有数据缓存机制. 我不会Sqllite. 感觉纯粹的SQLlite完全被coreData弱化了.这样不妥吗?

这两个东西我都用过，两者都能实现对数据库的操作，功能上需求都能满足。

先前在公司实习的时候，原先项目中用的是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，就应该坚持用下去，除非是真的碰到很致命的无法解决问题。中途换掉既有的自己熟悉的东西，费时费力，实际用起来没区别，得不偿失。

发布于
2013-02-28 5
条评论

赞同5

反对，不会显示你的姓名

知乎用户，iPhone
Developer

成岗、我这是好的、苏瑶 等人赞同

首先，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的方式实现,使用了多线程之后可以最大化的防止阻塞主线程。

发布于
2013-03-01 添加评论

赞同1

反对，不会显示你的姓名

林毅，ios
dev

鄭紫陽 赞同

CoreData 的数据模型升级兼容性比较差，如果模型不对，会导致程序连起都起不来。

虽然提供了模型升级代码，但是在客户端的管理模型版本管理也会相对复杂。

core data的好处是集成化，数据动态加载，icloud，包括上层的数据显示，都不需要重新进行数据装配，可以直接使用。

发布于
2013-04-05 添加评论

赞同1

反对，不会显示你的姓名

张俊，iOS开发

知乎用户 赞同

1.如果你的项目规模比较大，用coreData 可以减少你对存储管理的很多工作，否则你可能需要自己写很多的数据模型倒数据库操作的代码。

2.你的数据结构变化，数据迁移的时候coreData能帮你自动的完成，用sqlite 你就需要自己写代码来完成。

3.coreData还有些其他效率方面的优化，比如延迟写入。

对我自己而言，一般来说，如果没有复杂的 查询 需求，而数据量又比较小的话，我会用文件来做存储，自我感觉比较干净。如果涉及到比较多的数据，但是结构比较单一，表比较少，逻辑比较简单用sqlite也不错，但是如果你的表比较多，操作也比较多，还有升级迁移的需求，推荐使用coreData吧。

发布于
2013-02-28 1
条评论

赞同4

反对，不会显示你的姓名

megan
zhou，积跬步乃至千里，做好小事乃成大事。

bc wang、王化锋、知乎用户 等人赞同

我经常听人说，sqlite直接操作数据库，直接简单，效率也高。

但作为一个面向对象的开发者，coredata对我具有无限的吸引里。

真心喜欢它把数据模型都封装成对象，从开发的效率和代码的角度，我觉得coredata是如此的优雅。

另外，很多人在初始化coredata的数据的时候经常使用dictionary的setvalue：forkey方法，可伴随着学习的不断深入，我发现直接使用object.property = value就可以初始化mode。关键看你怎么封装了。

我想这也许是苹果极力推荐coredata的缘故吧。

coredata对于数据的处理能力还是很强的，你实在没有办法也可以结合sqlite一起使用。这就是所谓的原生sql吧。毕竟coredata是对于sqlite的封装。只是使用原生的时候要注意，coredata生成的字段前面都有个z，这个你查看一下表结构就可以很清晰的看到。

发布于
2013-07-24 添加评论

赞同0

反对，不会显示你的姓名

孙竟，专控萝莉
20 年

印象中（不知道后来更新没），CoreData 没有批处理。经我测试，批量插入、更新和删除数据时，比 SQLite 慢 2 个数量级。

举例来说，批量更新 1000 条数据，CoreData 用了 4 秒，SQLite 不到 0.1 秒。

再以 iReadG 为例，标记 100 条项目为已读并载入下 100 条未读项目要 10 多秒，期间啥都不能干。这种效率你能忍么？

当然，如果你的数据量小到任何数据库操作都不会让用户等待超过 1 秒，那就随意。

发布于
2013-03-01 4
条评论

赞同0

反对，不会显示你的姓名

李遥，A
Programmer

除了最简单的情况，一般来说ORM方案带来的麻烦比好处要多。尤其是项目到了后期变复杂时，ORM是最没有（开发+执行）效率也最容易制造隐藏bug的

编辑于
2013-03-06 添加评论

赞同0

反对，不会显示你的姓名

HUANG
Jerry

我以前的公司有自己的针对iphone的sqlite处理库（我自己开发的=w=），操作简单，功能比较完整，连数据迁移的功能都有，而且也有针对公司业务的具体情况。所以完全没有动力用coredata。

我记得我面试公司的时候老板问我（原本是想做JAVA的），“关于Hibernate，你觉得它的好处是什么？”。我很快就将标准答案答出来了，无非就是说数据处理的对象化。然后他接着问，为什么要将数据处理对象化。我大概说，因为这样可以加强代码的统一性等等。当时我是毕业生，并不明白他的用意，后来我知道了。在很多开发，这种代码的性质上的统一可能真的不是特别 实际。

我们公司做的程序有个特点，就是数据库版本更新特别多。最多纪录是半年内对一个app的数据库进行各种更新合共将近30次。此外还有其他一些特点：

为避免防止断电，程序出错、退出等各种状况造成数据不完整，每次数据有任何微小变动都要进行数据库写入，不过更重要的其实是直接用SQLite更新数据所动用的运算太少了，所以即使每次变动都更新问题都不大，倒也不是真的要做的万无一失。

数据量庞大而且增速快。每次日常基准操作大概会造成200-500条数据插入。一天大概要进行2-5次基准操作。这些操作会上传到服务器，而其他用户也能通过服务器下载，所以数据库里很容易看到某个表出现几十万条数据。

这种业务内容coredata其实是比较难以应付的。

当年老板告诉我他对对象化处理数据持久的看法。简单概括是“不灵活”。这也是我现在对CoreData的想法。

我举个例子吧，譬如说数据迁移，数据库的表格要变动了，这在CoreData的处理还是太过繁琐。而用我们公司的库，这仅仅是加入一个xml文件，里面存储了几条更新数据库的SQL而已。无论是删表还是加列加表都相当方便。xml有自己的版本，程序在启动的时候会检查数据库的版本和xml的版本而决定是否执行相关的SQL。这种做法带来的另外一个好处是，数据库的变动很容易追踪。CoreData的Model虽然直观，但其实比起那几条SQL，说实在，你能一下看出两个xml的SQL到底对数据库做了什么修改，但你未必能一眼看出两个CoreData的Model有什么不同。30个放一起，你想追踪这半年来你的数据库的变动，用CoreData的话会非常痛苦。

再有一个例子，像前面所说的，某个表已经有几十万个数据，然后要为这个表做些修改，譬如增加一个列，而列中的数据是基于其他表和这个表的一些数据进行初始化。CoreData要处理这种业务就相当困难。原本CoreData是要防止程序中加入太多数据处理代码，这种情况下CoreData反而因为不够灵活而必须涉及很多数据代码，这样的对象化数据处理真的有必要吗？相比之下SQL要处理这些问题可谓手到擒来。

但无论如何，我现在正在学用CoreData，主要是因为CoreData毕竟有它合适的地方。对于很多App来说，我们公司的那种App那样的数据业务状况是不常见的，CoreData在这个情况下还是比较方便的。毕竟不是每个公司都像我以前的公司那样构造一个完整的SQLite处理库，CoreData在这种情况下也算是一种通用语言。不过我必须说，CoreData用起来还是不够灵活。

发布于
2014-10-16 添加评论

赞同0

反对，不会显示你的姓名

AirSpuer，开始回答问题。

coredata,建立的表没有主键，添加时都要自己处理。

还有它不是关系型数据库，处理多对多的关系时比较麻烦。

发布于
2013-02-28 添加评论

赞同1

反对，不会显示你的姓名

handone

sharon
liao 赞同

我不懂代码，我找到了一些网上的东西，主要考虑解决coredata慢的问题，不知道下面的对不对：

苹果在iPhone 3.0以后的sdk中提供了Core Data功能，对于普通的数据库应用开发来说，大大提高了方便性。

　　新建Window Base Application的时候，选上下面的使用Core Data，模板就自动创建好了，在delegate文件里提供了使用Core Data存取数据的所有方法，在其它View Controller里面只要调用delegate里面的方法就可以了。而修改Data
Model并基于该Model创建Entity定义也提供了可视化的操