① sqlite版本升级做数据迁移怎么弄啊,求助
直接在现有基础上alter table就可以修改数据库结构了。 查看原帖>>
② android上有PropertyUtils的替代品吗
Realm是一个开源的面向对象移动数据库。上个月，Realm的Android版本发布了，比iOS版本晚了三个月。
我们之前已经报道过，Realm没有使用SQLite作为它的引擎，而是用C++写了自己的引擎，他们的目标是提供一个聚焦移动领域的SQLite的替代者。现在它的Android版本已经发布了。
当前Android上的Realm的API和iOS版本有点不同，这也反映了Objective C和Java的差别。Java版本的API有更高的强类型（strong-typed）要求，也更连贯（fluent）。
比如，在iOS上，查询是通过静态方法如"objectWhere"来进行的，这将返回一个RLMArray。这里的谓词都是基于字符串的。以下就是基于Object C的查询方法：
RLMArray *tanDogs = [Dog objectsWhere:@"color = 'tan' AND name BEGINSWITH 'B'"];
另一方面，在Android下进行相同的查询却是这样的：
RealmResults<Dog> tanDogs = realm.where(Dog.class)
.equalTo("color", "tan")
.beginsWith("name", "B")
.findAll();
当然，这有可能会被一种跨iOS、Android和其他平台的文本查询语言所替代。Tim Anglade是Realm的产品主管，他在一封邮件中指出，未来API的发展方向很大程度取决于社区的反馈。
虽然Realm是一个面向对象的数据库，但它和其他同类产品还是有一些明显的不同。Tim解释道，当它用原生对象格式（native object format）来存储数据时，这些对象不会带着其语言特有的格式原封不动地存在磁盘上，而是通过C++引擎存储在一个全局的表中。这使得Realm可以通过各种语言来访问数据，还包括各种即时查询（adhoc query）。
相比关系数据库，这种混合了对象和表的方式的优势在于它使图查询（graph query）更高效——甚至在相对老旧的智能手机上，查询深度嵌套的对象图也不会影响系统反应速度。Realm发布的基准测试（benchmark）结果称，在普通操作上，Realm的速度最快要达到原始的SQLite的10倍。
如果你现在有一个应用程序使用CoreData（iOS上）或SQLite（Android上），并且想迁移到Realm，肯定有一些事要做。这不是随便拿来就能用的——Tim解释说，CoreData和SQLite倾向于使用一种非常标准化的形式，这种做法在Realm上行不通。你最好从对象的角度重新思考你的模式（schema）和模型（model）。
一旦你修改了你的模式，使之适用于Realm，接下来把现有数据从CoreData/SQLite迁移过来就简单了。只要配置一次迁移操作（从Realm数据库版本0到版本1），在迁移过程中，把你的SQLite数据加载到Realm对象中并保存它们。
或者，如果你的数据保存在远程服务器上，你可以从头新建Realm数据库。
在采用Realm之前，必须要考虑到它是一个最前沿的软件，这意味着将来它的API有可能做出和以前不兼容的修改。
你可以通过Android版本的Realm来了解更多，或者查看Github上的代码。
③ iOS 开发如果涉及数据和表的持久化，Core Data 比 SQLite 更好吗
这两个东西我都用过，两者都能实现对数据库的操作，功能上需求都能满足。
先前在公司实习的时候，原先项目中用的是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，就应该坚持用下去，除非是真的碰到很致命的无法解决问题。中途换掉既有的自己熟悉的东西，费时费力，实际用起来没区别，得不偿失。
转载
④ 求助CoreData中是否有表对表数据迁移的方法,或者迁移表中部分数据
有几种思路：
1.写个导入导出程序
2.利用数据库自带的导入导出工具（大型数据库一般都有的）
3.sql脚本导入导出
⑤ ios 里面coredata怎么使用
搜扣丁学堂，有很多关于iOS中的CoreData的讲解： Core Data数据持久化是对SQLite的一个升级，它是ios集成的，在说Core Data之前，我们先说说在CoreData中使用的几个类。 （1）NSManagedObjectModel(被管理的对象模型) 相当于实体，不过它包含 了实体间的关系 (2)NSManagedObjectContext(被管理的对象上下文) 操作实际内容 作用：插入数据 查询 更新 删除 （3）NSPersistentStoreCoordinator(持久化存储助理) 相当于数据库的连接器 (4)NSFetchRequest(获取数据的请求) 相当于查询语句 (5)NSPredicate(相当于查询条件) (6)NSEntityDescription(实体结构) (7)后缀名为.xcdatamodel的包 里面的.xcdatamodel文件，用数据模型编辑器编辑 编译后为.momd或.mom文件，这就是为什么文件中没有这个东西，而我们的程序中用到这个东西而不会报错的原因
⑥ 如何使用Core Data
预加载/引入数据
那么我们究竟怎样把数据存储进Core Data数据库呢？目前有两种比较好的选择。
在App启动的时候从外部文件引入数据，就是在程序开始运行的时候从外部的资源，比如SQLite数据库或者XML文件中，引入数据。
提供一个已经制作完成的SQLite数据库，首先制作一个像上次的教程说的那样的数据库模型，之后在这个模型中填充数据，填充数据的方式是使用一个utility app，这个utility app可以是一个使用Core Data API填充数据库的Mac或者iOS app，也可以是一些直接填充数据库的程序。一旦数据库被填充之后，你就可以在没有已存在的数据库的情况下设置这个数据库未使用的默认数据库。
在这个教程中，我们会通过第二种，为大家展示如何使用一个简单的utility app来预加载一个已经装在好的Core Data数据库，以便让你的app使用。
第一步
我们在iOS上使用Core Data的方法的基础和我们在Mac OS X上使用的是一致的，他们使用同样的模型和类。
这一为我们可以写一个MAC OS X上的简单的console程序，来从数据源引入数据，再把这个数据库的数据库拿来给我们的iOS程序来用，不错吧？
我们来试试，首先打开Xcode，在 Mac OSX类中的Application中使用Command Line Tool 的模板。
我们就用 “CoreDataTutorial2” 作为工程的名字吧，记得使用“Core Data” 和 “Use Automatic Reference Counting” 。
完成创建之后，选择 “CoreDataTutorial2.xcdatamodeld” 彻底删除之。
⑦ IOS 存储方式（PList、NSUserDefaults、归档、CoreData、数据库、文件）
iOS开发，plist文件读写那些事 - (jianshu.com)
NSUserDefaults存储轻量级 的本地数据 ，比如要保存一个登陆界面的数据，用户名、密码之类的。
支持的数据类型有 NSString、 NSNumber、NSInteger、NSFloat、BOOL、NSArray、NSDictionary、NSDate、 等系统定义的数据类型。
用NSUserDefaults存储的数据下次程序运行的时候依然存在 .它的数据存储在应用程序内置的一个plist文件里, 在/Library/Prefereces沙盒路径下.
NSUserDefaults是定时把缓存中的数据写入磁盘的，而不是即时写入，为了防止在写完NSUserDefaults后程序退出导致的数据丢失，可以在写入数据后使用synchronize强制立即将数据写入磁盘：
使用NSKeyedArchiver 对数据进行 归档 反归档（将自定义类型转换为NSData类型:）
NSuserDefaults 的坑
iOS 最终，我还是决定放弃使用NSUserDefaults了 - (jianshu.io)
归档： ，就是将数据写到一个文件里面去。一般我们的应用的变量常量之类的数据都是在内存里面的，只要APP关闭，这些数据都会丢失。但是把数据存储到文件里面去，就能将数据保存到本地磁盘里面（目前iOS基本就是在沙盒里面操作了），不管是APP关闭还是重启设备，下次启动APP的时候都能够读出来。
解档： (别人也叫反归档)，就是将数据从文件里面读取出来。在程序里面使用。
【iOS】数据持久化：使用NSKeyedArchiver进行数据归档 - (jianshu.com)
iOS 开发Core Data使用方法 – 技术狗 (jishudog.com)
IOS 开发文件操作——NSFileManager - 星语海蓝 - 博客园 (cnblogs.com)
(15条消息) iOS文件操作_你有故事，我囿酒-CSDN博客
参考：
iOS开发 - 关于 NSUserDefaults 的使用 - (jianshu.com)
⑧ iOS 开发如果涉及数据和表的持久化，Core Data 比 SQLite 更好吗
首先，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的方式实现,使用了多线程之后可以最大化的防止阻塞主线程