★
如何权衡?
当你在权衡某个场合是否应该使用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,占用个几兆、十几兆还行,再大的话就不爽了。另外,对于手机操作系统,此招数效果不好(手机本身的内存就不是很大,而且存储介质的速度已经蛮快了)。
◇作为临时表
内存数据库方式,还可以用来充当临时表,存放一些临时数据。当程序的进程退出时,内存数据库就自然消失了,不会留下任何垃圾。
不过这种方式只适合于某个程序独占临时表的情形。如果临时表需要被多个进程共用,这招就不灵了。
当你在权衡某个场合是否应该使用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,占用个几兆、十几兆还行,再大的话就不爽了。另外,对于手机操作系统,此招数效果不好(手机本身的内存就不是很大,而且存储介质的速度已经蛮快了)。
◇作为临时表
内存数据库方式,还可以用来充当临时表,存放一些临时数据。当程序的进程退出时,内存数据库就自然消失了,不会留下任何垃圾。
不过这种方式只适合于某个程序独占临时表的情形。如果临时表需要被多个进程共用,这招就不灵了。