SQLite 适用场景

SQLite最佳试用场合

• 网站

  做为数据库引擎SQLite适用于中小规模流量的网站(也就是说, 99.9%的网站). SQLite能够处理多少网站流量在于网站的数据库有多大的压力. 一般来讲, 若是一个网站的点击率少于100000次/天的话, SQLite是能够正常运行的. 100000次/天是一个保守的估计, 不是一个准确的上限. 事实证实, 即便是10倍的上述流量的状况下SQLite依然能够正常运行.

• 嵌入式设备和应用软件

  由于SQLite数据库几乎不须要管理, 所以对于那些无人值守运行或无人工技术支持的设备或服务, SQLite是一个很好的选择. SQLite能很好的适用于手机, PDA, 机顶盒, 以及其余仪器. 做为一个嵌入式数据库它也可以很好的应用于客户端程序.

• 应用程序文件格式

  SQLite做为桌面应用程序的本地磁盘文件格式取得了巨大成功.例如金融分析工具、CAD 包、档案管理程序等等. 通常的数据库打开操做须要调用sqlite3_open()函数，而且标记一个显式本地事务的起始点（BEGIN TRANSACTION）来保证以独占的方式获得文件的内容. 文件保存将执行一个提交（COMMIT）同时标记另外一个显式本地事务起始点. 这种事务处理的做用就是保证对于应用程序数据文件的更新是原子的、持久的、独立的和一致的.

  数据库里能够加入一些临时的触发器,用来把全部的改变记录在一张临时的取消/重作日志表中. 当用户按下取消/重作按钮的时候这些改变将能够被回滚. 应用这项技术实现一个无限级的取消/重作功能只须要编写不多的代码.

• 替代某些特别的文件格式

  许多程序使用fopen(), fread(), 或 fwrite()函数建立和管理一些自定义的文件用来保存数据. 使用SQLite替代这些自定义的文件格式将是一种很好的选择.

• 内部的或临时的数据库

  对于那些有大量的数据须要用不一样的方式筛选分类的程序, 相对于编写一样功能的代码, 若是你把数据读入一个内存中的SQLite数据库, 而后使用链接查询和ORDER BY子句按必定的顺序和排列提取须要的数据, 一般会更简单和快速. 按照上述的方法使用内嵌的SQLite数据库将会使程序更富有灵活性, 由于添加新的列或索引不用重写任何查询语句.

• 命令行数据集分析工具

  有经验的SQL用户可使用SQLite命令行程序去分析各类混杂的数据集. 原是数据能够从CSV（逗号分隔值文件）文件中导入, 而后被切分产生无数的综合数据报告. 可能得用法包括网站日志分析, 运动统计分析, 编辑规划标准, 分析试验结果.

  固然你也能够用企业级的客户端/服务器数据库来作一样的事情. 在这种状况下使用SQLite的好处是: SQLite的部署更为简单而且结果数据库是一个单独的文件, 你能够把它存储在软盘或者优盘或者直接经过email发给同事.

• 在Demo或测试版的时候做为企业级数据库的替代品

  若是你正在编写一个使用企业级数据库引擎的客户端程序, 使用一个容许你链接不一样SQL数据库引擎的通用型数据库后台将是颇有意义的. 其更大的意义在于将SQLite数据库引擎静态的链接到客户端程序当中，从而内嵌SQLite做为混合的数据库支持. 这样客户端程序就可使用SQLite数据库文件作独立的测试或者验证.

• 数据库教学

  由于SQLite的安装和使用很是的简单(安装过程几乎忽略不计, 只须要拷贝SQLite源代码或sqlite.exe可执行文件到目标主机, 而后直接运行就能够) 因此它很是适合用来说解SQL语句. 同窗们能够很是简单的建立他们喜欢的数据库, 而后经过电子邮件发给老师批注或打分. 对于那些感兴趣怎样实现一个关系型数据库管理系统（RDBMS）的高层次的学生, 按照模块化设计且拥有很好的注释和文档的SQLite源代码, 将为他们打下良好的基础. 这并非说SQLite就是如何实现其余数据库引擎的精确模型, 可是很适合学生们了解SQLite是如何快速工做的, 从而掌握其余数据库系统的设计实现原则.

• 试验SQL语言的扩展

  SQLite简单且模块化的设计使得它能够成为一个用来测试数据库语言特性或新想法的优秀的原型平台.

不适用场景

• 客户端/服务器程序

   

  若是你有许多的客户端程序要经过网络访问一个共享的数据库, 你应当考虑用一个客户端/服务器数据库来替代SQLite. SQLite能够经过网络文件系统工做, 可是由于和大多数网络文件系统都存在延时, 所以执行效率不会很高. 此外大多数网络文件系统在实现文件逻辑锁的方面都存在着bug(包括Unix 和windows). 若是文件锁没有正常的工做, 就可能出如今同一时间两个或更多的客户端程序更改同一个数据库的同一部分, 从而致使数据库出错. 由于这些问题是文件系统执行的时候本质上存在的bug, 所以SQLite没有办法避免它们.

  好的经验告诉咱们, 应该避免在许多计算机须要经过一个网络文件系统同时访问同一个数据库的状况下使用SQLite.

• 高流量网站

  SQLite一般状况下用做一个网站的后台数据库能够很好的工做. 可是若是你的网站的访问量大到你开始考虑采起分布式的数据库部署, 那么你应当坚决果断的考虑用一个企业级的客户端/服务器数据库来替代SQLite.

• 超大的数据集

  当你在SQLite中开始一个事务处理的时候(事务处理会在任何写操做发生以前产生, 而不是必需要显示的调用BEGIN...COMMIT), 数据库引擎将不得不分配一小块脏页(文件缓冲页面)来帮助它本身管理回滚操做. 每1MB的数据库文件SQLite须要256字节. 对于小型的数据库这些空间不算什么, 可是当数据库增加到数十亿字节的时候, 缓冲页面的尺寸就会至关的大了. 若是你须要存储或修改几十GB的数据, 你应该考虑用其余的数据库引擎.

• 高并发访问

  SQLite对于整个数据库文件进行读取/写入锁定. 这意味着若是任何进程读取了数据库中的某一部分, 其余全部进程都不能再对该数据库的任何部分进行写入操做. 一样的, 若是任何一个进程在对数据库进行写入操做, 其余全部进程都不能再读取该数据库的任何部分. 对于大多数状况这不算是什么问题. 在这些状况下每一个程序使用数据库的时间都很短暂, 而且不会独占, 这样锁定至多会存在十几毫秒. 可是若是有些程序须要高并发, 那么这些程序就须要寻找其余的解决方案了.