SQLite的使用场景

上次针对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作为一个轻型数据库，方便干哪些事儿？
　　在这类场景中，由于是把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适合的场景 1:嵌入式设备手机,机顶盒,电视,游戏,照相机,手表,厨房电器,汽车,机床,飞机,遥感器,无人机,医疗器械,机器人 2:应用文件格式桌面应用,如版本控制系统,财物分析工具,媒体 ...
使用SQLite的感想
最近都在使用SQLite数据库,老实说这才是我使用的第三款数据库而已.使用它原因就应为它够轻量,而且性能挺不错.但使用久了也发现了一些问题.偶尔也会有怨言,但也不会骂SQLite是个破东西之类的,原因 ...
Sqlite研究系列-1
文章目录简介架构简介 sqlite是一个开源的嵌入式关系型数据库.与常规数据库不同的地方是: 零配置没有账号概念客户端和服务端运行在应用程序的进程空间,不需要网络配置 sqlite可以编译到 ...
mysql的sleep线程多久_MySQL数据库sleep线程过多，怎么办？
推荐文章要想知道每个数据库的大小的话,步骤如下:1.进入information_schema 数据库(存放了其他的数据库的信息) use information_schema; 2.查询所有数据的大 ...
azure mysql数据库_Azure上创建MySql数据库服务
推荐文章要想知道每个数据库的大小的话,步骤如下:1.进入information_schema 数据库(存放了其他的数据库的信息) use information_schema; 2.查询所有数据的大 ...
Django 教程之数据库模型
切换数据库按需更换,如需更换,建议开发初期就开始切换 Django默认的数据库SQLite SQLite是一个轻量级的开源免费的数据库.它是一种嵌入式数据库,只是一个.db格式的文件,无需安装,配置 ...
Python高并发应用场景下四种写入SQLite数据库的速度比较
"Python小屋"编程比赛正式开始中国大学MOOC"Python程序设计基础"第5次开课推荐图书: <Python程序设计基础(第2版)>,I ...
Android SQLite数据库之事务的学习
SQLite是Android系统内置的一款轻量级的关系型数据库,它的运算速度非常快,占用资源很少,通常只需要几百K的内存就足够了.SQLite不仅支持标准的SQL语法,还遵循了数据库的ACID事务. ...
【数据库】SQLite和MySQL之间的对比和选择
目录 1.各自特定 2.使用场景 3.选择哪个 1.各自特定 SQLite :独立.简单(零配置):适用于为单个应用程序和设备提供本地数据存储. MySQL:可伸缩.高并发性:适用于客户端/服务器模式 ...

SQLite的使用场景

SQLite的使用场景相关推荐

最新文章

热门文章