SQLite的适合用户

1.         SQLite与其它大部分SQL数据库引擎的区别在于它的主要设计目标是简单化：

• 简单去管理
• 简单去操作
• 简单去嵌套于大程序
• 简单去维护与定制

        很多人喜欢SQLite，因为它的小与快。不过这些能力只是个愉快的意外。用户也发现SQLite是非常可靠的。可靠性是简单化的结果。因为不复杂，所以少有机会出错。因此，SQLite是小的、快的与可靠的，不过首要的和最重要的原因是SQLite力求简单。

        数据库引擎的简单化可以是长处也可以是短处，依赖于你试着做什么。为了实现简单化，SQLite必须牺牲其它的人们认为有用的特性，如高并发、细粒度访问控制、嵌入结构的富集合、存储过程、深奥的SQL语言特性、XML与/或Java扩展、兆兆或千兆字节可扩展型等等。如果你需要这些功能并且不在乎它们带来的复杂性，SQLite或许不是你想要的数据库。SQLite并不想成为企业数据库引擎。它并不为与Oracle或PostgreSql竞争。

        什么时候适合使用SQLite的基本拇指规则是：使用SQLite在管理、实现与维护简单性比企业数据库引擎提供的数不胜数的负责特怔更重要的情况。结果是，在简单性是一个不错选择的环境下比人们认为的更通用。

        另一个看待SQLite的方式是：SQLite不为替换Oracle设计。它是为替换fopen()而设计。

SQLite工作更好的环境

• 应用程序文件格式
  SQLite已经成功用作桌面应用程序的磁盘文件格式，如版本控制系统、财务分析工具、媒体分类与编辑组件、CAD包、记录程序等等。传统的File/Open操作调用sqlite3_open()关联数据库文件。更新在应用程序内容改变的时候自动发生，因此File/Save菜单选项变得不必要。File/Save_As菜单选项可以通过使用backupAPI实现。
  
  将SQLite用于作为应用程序文件格式有许多有点，包括：
  
  1. 不需要文件解析与产生写与调试的代码。
  2. 内容可以通过使用强大的SQL查询语句访问与更新，极大地削减了应用程序代码的复杂性。
  3. 为后绪版本的新功能扩展文件格式如同添加新表或在现存表中添加新列一样简单。
  4. 否则，不同的内容将以可以封装成单独磁盘文件的文件堆形式保存。
  5. 内容可以使用第三方工具查看。
  6. 应用程序文件是在所有操作系统中方便传输，32位与64位、大端与小端体系。
  7. 应用程序仅仅需要加载需要多的数据，而不是读取整个应用程序文件并且在内存中保留完整的解析。启动时间与内存消耗被削减。
  8. 小的编辑仅仅重写改变的文件部分而不是整个文件，因此提高了性能与削减了SSD驱动上的损耗。
  9. 内容被连续且自动更新，因此在电源出错或崩溃的情况下没有工作丢失。
  10. 应用程序可以支持富文本搜索与RTREE功能，它们集成在SQLite中。
  11. 性能问题可以经常通过使用CREATE INDEX的方式解决，而不是重新设计、重写与重新测试应用程序代码。
  12. 程序联盟，或许以不同程序语言写的，都可以访问相同应用程序文件，而不用考虑兼容性。
  13. 多个进程可以关联同一个应用程序文件，并且可以读取和写入而不相互影响。
  14. 跨回话的undo/redo可以使用trigger实现。
  15. 在很多通用情况，从SQLite数据库中载入内容比从单个文件中载入内容要快。更多信息，参考内部VS外部BLOBs。
  16. 保存在SQLite数据库中的内容在原始应用程序的所有轨迹都丢失之后，更容易在将来重新获取。
  SQLite准许数据库文件拥有任何期望的文件扩展名，因此，应用程序为了它自己的使用，如果希望可以选择自定义的文件扩展名。应用程序ID语法用于在数据库文件中设定“应用程序ID”整数，因此类似file(1)的工具可以决定关联你应用程序的文件，它不仅仅是一个通用的SQL数据库。
• 嵌入设备与应用程序
  因为SQLite数据库很少需要或不需要管理者，SQLite对于必须工作于无人照顾与无人支持的设备或服务下是个很好的选择。SQLite非常适合用于手机、PDAs、机顶盒或家用电器。它作为可下载应用程序的嵌入式数据库也工作很好。
• 网站
  SQLite作为中等通信量网站（也即是说，所有网站的99.9%）的数据库引擎也工作很好。当然，SQLite可以处理的网站通信量大小取决于该网站多大量地使用它的数据库。通常来讲，任何每天点击量少于100k的网站使用SQLite都可以工作很好。每天100K的点击量是个保守的统计，并不是硬性的上限。SQLite已经展示以10倍于通信量的情况工作。
• 替换特殊磁盘文件
  很多程序使用fopen()、fread()与fwrite()去创建与管理自产的数据文件。SQLite作为这些临时数据文件的替代物工作尤其出色。
• 内部或临时数据库
  对于那些用于必须以各种方式筛分与排序的大量数据的程序来说，它通常更容易、更快加载数据到内存SQLite数据库，并且可以使用具有jion与ORDER BY的查询语句以表格或需要的排序形式提取数据，而不是尝试人工编写相同操作的代码。通过这种方式内部使用SQL数据库也给予程序更大的灵活性，因为新列与索引可以添加进来而不取用重写每个查询。
• 命令行数据集分析工具
  有经验的SQL用于可以使用命令行sqlite3程序去分析各种各样的数据集。原始数据可以从CSV文件中导入，然后数据可以被切分产生多种总结报告。可能用于包括网站日志分析、运动统计分析、程序编译测量与实验结果分析。
  当然，你也可以通过商业客户/服务器数据库实现相同的东西。在该情况下使用SQLite的优势在于SQLite很容易设置，并且数据库结果为一个独立的文件，你可以保存在软盘或闪存棒中或给同事发邮件。
• 在例子或测试中是商业数据库的替身
  如果你正在为一个商业数据库引擎写一个客户端应用程序，使用通用后端数据库是有意义的，它准许你连接多种SQL数据库引擎。继续下去或许更有意义，将SQLite引入支持数据库的混合使用中与在客户端静态连接SQLite引擎。这种方式，客户端程序可以脱机使用SQLite数据文件于测试或展示。
• 数据库教学
  因为它设置与使用都很简单（安装是不重要的：只要拷贝sqlite3或sqlite3.exe可执行文件到目标机器并且运行它），SQLite对于教SQL来说是个很好的数据库引擎。学生可以很容易创建它们喜欢的数据库并且将该数据库发邮件给导师评价或打分。对于对RDBMs如何实现感兴趣的更高级学生来说，模块快、良好注释与文档花的SQLite代码可以充当好的基础。这并不是说SQLite是其它数据库引擎实现的精确模型，而是说理解SQLite如何工作的学生可以快速理解其它系统的操作原理。
• 实验性SQL语言扩展
  简单、模块化的SQLite设计是设计新的、实验性数据库语言特征或思想的较好平台。

其余RDBMs可以更好工作的环境

• 客户/服务器应用程序
  如果你很多客户端程序通过网络访问一个通用数据库，你应该考虑使用一个客户/服务器数据库引擎而不是SQLite。SQLite将工作于网络文件系统，不过由于潜在关联很多网络文件系统，性能或许不好。很多网络文件系统的文件锁逻辑实现也包含bugs（在Unix与Windows上）。如果文件加锁并不像应有的那样工作，它或许是因为同一时间两个以上的客户端程序修改相同数据库的相同部分，结果数据库腐化了。因为这个问题结果原于底层文件系统实现的bug，SQLite不能够预防它。
  一个良好的拇指规则是，你需要避免使用SQLite在这些情况，多个相同数据库会被网络文件系统上的很多电脑同时访问。
• 高访问量网站
  SQLite通常作为一个网站的数据库后端工作很好。不过如你的网站相当忙碌，以至于你需要考虑分割数据库组件在另一个机器上，这时你需要明确考虑使用商业类型的客户/服务器数据库引擎替换SQLite。
• 非常大的数据集
  一个SQLite数据库限制大小于140TB（2⁴⁷字节，128兆兆字节）。即使它能够处理更大的数据库，SQLite保存整个数据库于一个单独的磁盘文件，且很多文件系统限制文件的最大大小比这个小。因此，如果你考虑的数据库在这个数量级，你需要考虑使用那些在多个磁盘文件上或多个卷上扩展它的内容的客户/服务器数据库引擎。
• 高并发性
  SQLite支持不限制数量的同时读，不过它仅仅准任何实例的一次一个写。在很多情况，这并不是个问题。每个应用程序很快处理它的数据库工作，并且持续不会多于几微妙。不过有一些应用程序需要多并发性，这些应用程序需要寻求不同的解决方案。