关于SQLite，SQLCipher和FMDB
SQLite是一个轻量的、跨平台的、开源的数据库引擎，它的在读写效率、消耗总量、延迟时间和整体简单性上具有的优越性，使其成为移动平台数据库的最佳解决方案（如iOS、Android）。然而免费版的SQLite有一个致命缺点：不支持加密。这就导致存储在SQLite中的数据可以被任何人用任何文本编辑器查看到。
如果我们想要使得自己的数据库加密，解决方案就是使用另一款开源的加密数据库SQLCipher，SQLCipher使用256-bit AES加密，由于其基于免费版的SQLite，主要的加密接口和SQLite是相同的，当然也增加了一些自己的接口，如在新建和打开数据库时，给数据库设置秘钥之类的操作。
FMDB是一个开源的类库，它对sqlite数据库操作进行了很不错的封装，而且也增加了对sqlcipher的支持，也就是说，我们不直接用sqlcihper也能完成加解密操作，而且FMDB在操作sqlite方面方便得多。现在的APP开发如果涉及到数据库操作，FMDB基本上是首选。
下面内容主要是针对一些在初期忽略了数据库私密性，而到了中期需要让数据库进行升级加密的App的简单方案介绍和代码实现。如果读者没有使用FMDB，直接使用了sqlite，那本文也有一定参考性，只是关于SQLCipher的配置，并没有介绍，因为虽然FDMB的加密也是使用SQLCipher，但是不需要进行配置的。
具有加密功能的FMDB版本
加密的FMDB其实是一个分支，也就是说，如果你需要替换FMDB。Github上关于该分支的安装只提供了cocospod的安装方式。
Github上FMDB的地址：https://github.com/ccgus/fmdb
举个例子，如果你以前是如下写的
| 1 | pod 'FMDB' |
如果想换成有加密功能的，就改成
| 1 | pod 'FMDB/SQLCipher' |
升级数据库代码实现
得到对的版本后，我们需要在代码里做一些处理，让旧数据库升级。这里升级包括两点：
1 是我们前面所说的，将数据库加密。
2 把旧数据库的表和数据迁移到新数据库中。
sqlcipher的使用和sqlite没有多大的区别，有一点值得注意便是每次当[dp open]成功后，需要给数据库配上口令，即[db setKey:DB_SECRETKEY]， DB_SECRETKEY是我们的一个自定义宏。这之后，我们才能读出数据库的内容。
| 1234567 | FMDatabase *_db = [FMDatabase databaseWithPath:[cachePath stringByAppendingString:dbFileName]];if (![_db open]) { _db = nil; return;}else{ [_db setKey:DB_SECRETKEY];} |
然后我们需要判断数据库是否需要升级，当使用sqlchipher打开用sqlite生成的源数据库时，[dp goodConnection]是为NO，即使上面[db open]操作是YES。
| 123 | if(![_db goodConnection]){ //无效连接 [self upgradeDatabase:dbpath];} |
接下来，便是数据迁移，path是我们的源数据库路径，假设我们的源数据库名字为DBName，changeDatabasePath即将我们的数据库A改名为DBName.tmp，接下来便是，新建数据库B，因为A在前面已经进行了改名为DBName.tmp，并且已经B将来就是我们要取代A的数据库，所以此处的B名字便是DBName。最后将DBName.tmp的数据复制到DBName中，再删除DBName.tmp，致此，我们的数据库便升级完成了。
经过上面步骤，我们知道虽然sqlchipher是基于sqlite的，但到底还是不一样的，我们没办法直接将sqlite的数据库升级为sqlchipher，只能用sqlchipher新建一个数据库，再重新写入数据。
以上代码仅仅是范例，各个App的数据存储模型不尽相同，这里我也没办法给出模板。虽然代码不一定是适用的，但是在数据库升级时，代码执行的先后顺序是肯定的：打开数据库open -> 设置秘钥 setkey -> 查看连接 goodConnection -> 新建数据库并迁移数据 upgrade。