为项目中使用了Core Data而没用SQLite感到很后悔。
我至今发现Core Data最大的优点就是NSFetchedResultsController了，这个对在表格里显示大量数据有好处。缺点发现一大堆：
1. 代码冗长，一个带条件的查询些下来要十行，最后封装了一下好了一点，最大的问题是Core Data的API太另类了，加上objc，代码看起来真别扭，跟传统数据库查询差异太大。当然了Core Data不是数据库，它更像是带查询的对象持久化。
2. 升级困难，官方文档用了Migration而不是upgrade，实际上对比较大幅度的改变，根本就是没法升级，只能把内容在新的存储介质中重建，这效率肯定上不去啊！这个应该是Core Data设计的问题，人家不是数据库。但这个后端存储不能灵活变化真是硬伤呐！另一个小问题是我做版本映射的时候，child entity没有默认把parent entity的属性做映射，然后数据都丢掉了，debug了半天才发现这个问题，最后得自己手动把parent entity的属性都加上。
3. 用复杂SQL可以一句搞定的东西在Core Data里只能一步步用Core Data的API搞
4. 线程问题，我有一个后台线程处理数据同步，但前端用户可能还会继续写入数据，最后我改成让core data在主线程上工作才解决这个问题，这不是个好办法，我还得再研究研究。
但现在太晚了，要是再换成传统数据库又得烧进大量时间。请问大家怎么看Core Data？或者您在项目中用了那种数据持久化方案？
我至今发现Core Data最大的优点就是NSFetchedResultsController了，这个对在表格里显示大量数据有好处。缺点发现一大堆：
1. 代码冗长，一个带条件的查询些下来要十行，最后封装了一下好了一点，最大的问题是Core Data的API太另类了，加上objc，代码看起来真别扭，跟传统数据库查询差异太大。当然了Core Data不是数据库，它更像是带查询的对象持久化。
2. 升级困难，官方文档用了Migration而不是upgrade，实际上对比较大幅度的改变，根本就是没法升级，只能把内容在新的存储介质中重建，这效率肯定上不去啊！这个应该是Core Data设计的问题，人家不是数据库。但这个后端存储不能灵活变化真是硬伤呐！另一个小问题是我做版本映射的时候，child entity没有默认把parent entity的属性做映射，然后数据都丢掉了，debug了半天才发现这个问题，最后得自己手动把parent entity的属性都加上。
3. 用复杂SQL可以一句搞定的东西在Core Data里只能一步步用Core Data的API搞
4. 线程问题，我有一个后台线程处理数据同步，但前端用户可能还会继续写入数据，最后我改成让core data在主线程上工作才解决这个问题，这不是个好办法，我还得再研究研究。
但现在太晚了，要是再换成传统数据库又得烧进大量时间。请问大家怎么看Core Data？或者您在项目中用了那种数据持久化方案？
Select Language