SQLite介绍及使用场景

SQLite 是遵守ACID 的關聯式資料庫 管理系统，它包含在一个相对小的C 库 中。它是D.RichardHipp 建立的公有领域 项目。

不像常见的客户-服务器 范例，SQLite引擎不是个程序与之通信的独立进程，而是连接到程序中成为它的一个主要部分。所以主要的通信协议是在编程语言内的直接API 调用。这在消耗总量、延迟时间和整体简单性上有积极的作用。整个数据库（定义、表、索引和数据本身）都在宿主主机上存储在一个单一的文件中。它的简单的设计是通过在开始一个事务的时候锁定整个数据文件而完成的。

库实现了多数的SQL -92标准，包括事务 ，就是代表原子性 、一致性 、隔離性 和持久性 的（ACID ），触发器 和多数的复杂查询。不进行类型检查 。你可以把字符串 插入到整数 列中。例如，某些用户发现这是使数据库更加有用的创新，特别是与无类型的脚本语言一起使用的时候。其他用户认为这是主要的缺点。

多个进程 或线程 可以访问同一个数据而没有问题。可以并行的满足多个读访问。只有在其他访问当前不被服务的时候才能满足写访问；否则写访问失败并带有一个错误代码（也可以在可配置的超时过期之后自动的重试）。

提供了叫做sqlite 的一个独立程序用来查询和管理SQLite数据库文件。 它也充当写使用SQLite库的应用的一个例子。

可以从C/C++程序中使用这个库，还可以获得对Tcl 和一些其他脚本语言 的绑定。

在CPAN 的DBD::SQLite 上有一个Perl 的DBI/DBD 模块，它不是到SQLite的接口，而是包括整个SQLite数据库引擎在其中并不需要任何额外的软件。

还有一个Python模块叫做PySQLite 。

PHP 从PHP 5.0开始經包含了SQLite，但是自5.1版之後，SQLite開始成為一個延伸函式庫。SQLite能与PHP4一起工作，但不包含在PHP4裡面。

Rails 2.0.3将缺省的数据库配置改为了SQLite 3。

SQLite亦可以作为桌面数据库使用，以下为第三方SQLite的GUI 软件。例如，

• SQLiteMan ，使用QT开发的一个SQLite客户端，支持多语言、跨平台。SQLiteMan
• SQLite Manager ，以Firefox 浏览器的扩展形式提供的SQLite客户端。
• SQLite Database Browser ，a graphical client to access SQLite databases
• SqlPro SQL Client ，another graphical client to work with SQLite databases

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

<!-- program-think-->

　　★如何权衡？
　　当你在权衡某个场合是否应该使用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作为一个轻型数据库，方便干哪些事儿？
　　在这类场景中，由于是把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，占用个几兆、十几兆还行，再大的话就不爽了。另外，对于手机操作系统，此招数效果不好（手机本身的内存就不是很大，而且存储介质的速度已经蛮快了）。

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