开源实践：SQLite 的使用场景

　　上次针对 SQLite 进行了扫盲，之后有同学在评论里问俺：如何在项目中使用它？今天咱来聊一下这个话题。

★如何权衡用不用？

　　当你在权衡某个场合是否应该使用 SQLite 时，（在技术层面）至少要考虑如下几点：
◇能否发挥 SQLite 的某些特长？
◇是否还有其它的替代方案？
◇是否有啥潜在的技术风险？
　　想清楚上述问题之后，再做出决策。

★SQLite 的特点

　　关于 SQLite 的强项，在上次的帖子中已经介绍过了。考虑到某些同学比较健忘，咱再回顾一下：
◇文件型数据库，且只有单一数据文件
◇轻量级
◇绿色（不依赖其它软件库）
◇跨平台（包括引擎和数据文件）
◇支持内存数据库
◇支持较大的数据文件（TB级别）

★可能的替代方案

　　刚才说了，权衡 SQLite 的使用需要考虑其它的替代方案，所以俺简单介绍一下和 SQLite 用途相近的其它几种技术手段。后面讲应用场景的时候，会结合这几个替代方案来作对比。

◇Access 数据库

　　Access 数据库也是文件型的数据库，支持的很多 SQL 特性都类似于 SQLite。自从 Windows 2000 开始，Windows 就内置了 Access 的数据库引擎（Microsoft Jet Database Engine）。所以，Access 数据库在 Win2000 及后续版本的系统中是可以独立运行滴（不依赖 Office）。
　　Access 数据库的缺点包括：
1. 不能跨平台
2. 文件大小有限制（最大只能到 2GB）
3. 【不】支持内存数据库。

◇其它文件型数据库

　　其实，除了 Access 之外，还有另外一些文件型数据库。但是这些文件型数据库要么名气太小，要么不支持多种编程语言（比如：HSQLDB），要么已经过时（比如：FoxPro、Paradox）。所以后面分析应用场景的时候，俺就不再提及这几个玩意儿。

◇CSV 文件

　　CSV（Comma Separated Values）是一种很简单的纯文本格式。它本身就是用来表示二维的数据信息的。一个 CSV 文件可以理解为数据库的一张表。
　　CSV 的缺点主要在于：
1. 【无法】直接存储非文本的数据信息（比如 BLOB 类型的信息）
2. 如果需要同时存储多张表的信息，就需要对应有多个 CSV 文件（文件一多，管理起来就嫌麻烦）
3. CSV 文件【无法】体现表之间的外键关联

◇XML 文件

　　XML 文件想必大伙儿都知道，俺就不多解释了。
　　XML 格式主要缺点包括：
1. XML 本身是树状结构，有时候不便于表示二维数据表的信息
2. 一旦数据量大（比如文件超过 10MB 或者 XML 节点层次很深）的时候，解析的开销（包括空间和时间）就不容忽视了

★作为数据库的应用场景

　　前面说了一大通，现在开始切入正题，先说说 SQLite 作为一个轻型数据库，方便干哪些事儿？
　　在这类场景中，由于是把 SQLite 作为数据库来使的，所以基本不用考虑 CSV 和 XML 这两种替代方案。

◇需要数据库的小型桌面软件

　　如果你开发一个小型的桌面软件并且需要用到数据库功能（比如某个背单词软件），那 SQLite 是一个不错的选择。因为 SQLite 很绿色又很短小精悍。
　　不过，由于 Windows 在桌面系统的比重很大。对于那些【不考虑】跨平台的开发人员，SQLite 相对于 Access 来说，没有太大的优势。

◇需要数据库的手机软件

　　眼下手机应用的发展很迅猛，相应的开发人员也多起来了。假如你就是一个手机应用程序的开发人员，并且你开发的应用需要有数据库功能（比如某个字典工具），那 SQLite 简直是不二之选。由于手机操作系统名目繁多，同时手机的内存偏小，这时候 SQLite 跨平台和轻量级的特长就充分发挥出来了。目前几个知名的手机操作系统（比如“Android、Windows Mobile、Symbin、Palm”），SQLite 都支持得不错。
　　对这类场合，Access 基本没戏。

★作为数据容器的应用场景

　　所谓数据容器，就是把 SQLite 作为装数据的容器，充分发挥 SQLite 【单一数据文件】的优点。另外，还可以避免自己定义一套数据文件格式的麻烦。要知道，自己定义一个【完善的】数据文件格式是难度极大滴（要考虑可扩展性、要考虑向下兼容、假如跨 CPU 架构还要考虑字节序、假如数据量大还要考虑性能、还要...）。

◇数据备份/恢复、数据导入/导出

　　某些软件系统（尤其是些企业应用系统）经常会碰到数据备份/恢复的功能需求。比如说，客户会要求你把一些数据（往往是业务相关的）定期备份成一个【独立的】数据文件，然后存储在别处。一旦软件系统自身发生不测，再把备份的数据恢复回来。
　　另外，导入/导出功能也是经常碰到的。一般是某个软件安装在多个地方。然后需要把一些数据（往往是业务相关的）从 A 处导出，然后在 B 处导入。
　　针对上述这两种需求：如果牵涉的数据比较大，就不宜使用 XML 或者 Access；如果牵涉到跨平台，就【无法】使用 Access；如果牵涉到多种业务数据结构，就不宜使用 CSV（除非你能忍受多个 CSV 文件并存）。有上述条件限制的地方，都很适合用 SQLite。

◇在线升级

　　这年头不联网的单机已经很少了，提供在线升级功能的软件会多起来。一般的在线升级分为两类：升级程序（比如 Firefox 自动升级新版本）和升级业务数据（比如杀毒软件升级病毒库）。这两种类型都可以使用 SQLite 来完成。把需要要升级的内容放置到 SQLite 数据库文件中，将来升级时只需下载【单一】的升级文件即可。
　　在这种场景，不太合适用 CSV 和 XML。如果不考虑跨平台，倒也可以用 Access 来搞定。

★作为内存数据库的应用场景

　　在这种类型的场景中，咱们要充分发挥 SQLite 内存数据库的特长。由于 SQLite 的 API 设计比较合理，操作内存数据库和操作文件数据库几乎没啥区别，所以从“文件型”切换到“内存型”，代码【无需】大改。
　　另外，从3.6.11开始，SQLite 增加了online backup接口，便于在内存数据库和文件数据库之间进行数据的同步。

◇降低磁盘 I/O 开销

　　比如开发了某个字典工具，词库存储在 SQLite 数据库文件中。当词库越来越大的时候，你可能会发现，查词的速度越来越慢。当然啦，速度慢未必是磁盘 I/O 引起的。这时候你可以把程序略微修改一下（可能就10行左右的代码），在初始化时把词库载入内存的 SQLite 数据库中。然后再对比测试一下性能。如果发现性能有明显提升，那你以后就可以一直用这种方式了。
　　使用这个招数，要小心内存数据库对内存空间的占用。比如对于普通的 PC，占用个几兆、几十兆还行，再大的话就不爽了。另外，对于手机操作系统没必要用此招数——手机的存储介质本身已经够快了。

◇作为临时表

　　内存数据库方式，还可以用来充当临时表，存放一些临时数据。当程序的进程退出时，内存数据库就自然消失了，不会留下任何垃圾。
　　不过这种方式只适合于某个程序独占临时表的情形。如果临时表需要被多个进程共用，这招就不灵了。


俺博客上，和本文相关的帖子（需翻墙）：
开源点评：SQLite 数据库扫盲