sqlite应用场景

★如何权衡？
　　当你在权衡某个场合是否应该使用SQLite时，（在技术层面）至少要考虑如下几点：
　　◇能否发挥SQLite的某些特长？
　　◇是否还有其它的替代方案？
　　◇是否有啥潜在的技术风险？
　　想清楚上述问题之后，再做出决策。
　　★SQLite的特点
　　关于SQLite的特长，在上次的帖子中已经介绍过了。考虑到某些同学比较健忘，咱再回顾一下：
　　◇文件型数据库，且只有单一数据文件
　　◇轻量级
　　◇绿色（不依赖其它软件库）
　　◇跨平台（包括引擎和数据文件）
　　◇支持内存数据库
　　◇支持较大的数据文件（TB级别）
　　★可能的替代方案
　　刚才说了，权衡SQLite的使用需要考虑其它的替代方案，所以俺简单介绍一下和SQLite用途相近的其它几种技术手段。后面讲应用场景的时候，会结合这几个替代方案来作对比。
　　◇Access数据库
　　Access数据库也是文件型的数据库，支持的很多SQL特性都类似于SQLite。自从Windows 2000开始，Windows就内置了Access的数据库引擎（Microsoft Jet Database Engine）。所以Access数据库在上述系统中也是可以独立运行的（不依赖Office）。
　　Access数据库最主要的缺点就是不能跨平台。另外还有几个小缺点：文件大小有限制（2GB）、不支持内存数据库。
　　◇其它文件型数据库
　　其实，除了Access之外，还有另外一些文件型数据库。但是这些文件型数据库要么名气太小，要么不支持多种编程语言（比如HSQLDB），要么已经过时（比如FoxPro、Paradox）。所以后面分析应用场景的时候就不再提及这些玩意儿。
　　◇CSV文件
　　CSV（Comma Separated Values，详细解释见“这里”）是一种很简单的纯文本格式。它本身就是用来表示二维的数据信息的。一个CSV文件可以理解为数据库的一张表。
　　CSV的缺点主要在于：不便于存储非文本的数据信息（比如BLOB类型的信息）；如果需要同时存储多张表的信息，就需要对应有多个CSV文件（文件一多，就嫌麻烦）。
　　◇XML文件
　　XML文件想必大伙儿都知道，我就不多说了。XML格式主要缺点也有两个：一个是由于XML本身是树状结构，有时候不便于表示二维数据表的信息；另一个是数据量大（比如文件超过10MB或者XML节点层次很深）的时候，解析XML的开销蛮大的。
　　★作为数据库的应用场景
　　前面说了一大通，现在开始切入正题，先说说SQLite作为一个轻型数据库，方便干哪些事儿？
　　在这类场景中，由于是把SQLi