sqlite,mysql,access对比

lbdbzj110

　　SQLite是一个小型的桌面型数据库，轻量级的，绿色、开源、轻便。
　　SQLite其实只是一个文件，以及内部格式方案而已。下面做几个简单的对比：
　　SQLite VS 文本文件或二进制文件：
他们的本质是相同的，都是一个文件。但是SQLite定义了更加复杂的内部结构。而我们一般写程序进行的文本文件读写，只是把它当成了一种文本的存放对象。而二进制文件，或者记录文件，则是当成了某种单一的数据类型的存放而已。如果把文本或二进制文件扩展开来，可以同时存放多种数据，并规定好相应的协议、规则，那么就是SQLite的雏形。
　　SQLite VSAccess：
他们都是单文件的，也都不需要额外的数据库服务器进行控制。但是Access作为微软的产品，有官方的管理平台Access软件，同时在Windows里面也内置了对其进行访问的API。而SQLite则是非官方的。另外，Access还和VBA捆绑在了一起，形成了全套的开发平台，你要是愿意，甚至可以在Access里面折腾出一套MIS来，当然很不好用。而SQLite则是纯粹的数据存储。另外，文档方面，Access的文档简直是神秘得不得了，做了这么多年编程，一直没有找到Access的完整的文档，只是零零碎碎的积累了一点点，而且好多还是多次调试才试探出来的。而SQLite则是有公开的文本，并且支持SQL92。SQLite相比Access，还有一个好处就是管理平台也是轻量级绿色的，不需要去安装Office软件那么麻烦。
　　SQLite VSmysql：
二者都是开源的，也都是号称轻量级数据库。但是SQLite是文件型的数据库，只要一个文件，就可以走遍天下；而mysql需要安装相应的服务器软件，并且需要挂载。然后SQLite只是一个文件，而mysql则是一个文件夹下的一组文件。
　　至于其他的数据库产品，接触的不多，就不比较了。反正个人觉得这个是一个轻量级开发的好东西，尤其适合我这样的开发人员。因为应用环境的限制，我的产品需要轻量级、绿色、高效率、易管理等等特性，毕竟不是人人都能安装SQL Server，而其他一些数据库又不怎么合适。
　　下一步的开发，可能慢慢不再使用Access，而是逐步转移到SQLite上面来。
　　不过呢，Access还是有一个优势的，那就是和SQL Server之间的互转换性能比较好，如果更换数据库，代码变更量比较小。而SQLite在这一点上就不行了。而我的产品，有时还是要考虑SQLServer的，毕竟有些应用的数据量还是挺大的……
　　mysql需要安装
sqlite不需要
　　
　　大部分的小系统都是用Access数据库，有的系统为了掩盖数据库的类型，把数据文件后缀名改了，其实只要改回到mdb，用Access打开，数据一目了然，其实Access数据库本身有很多的问题：性能不行；数据不安全，用户可以直接用Access打开数据库文件进行数据修改，即使加密后都可以直接破解；Access的数据量一大，文件本身的体积就异常庞大；Access数据库文件很容易损坏，我做的一个系统由于意外断电老是当掉，用户的数据几经摧毁。 为了弥补Access的缺陷，我曾经用MySQL数据库代替，但MySQL是网络数据库，安装起来比较复杂。后来在用Python做项目的时候发现了SQLite，真是相见恨晚，SQLite就是Access理想的替代品啊！
　　SQLite是一个小型的C程序库，实现了独立的，可嵌入的，零配置的SQL数据库引擎。特性包括：

• 事务操作是原子，一致，孤立，并且持久的(ACID)，即使在系统崩溃和电源故障之后。
  
• 零配置——不需要安装和管理。
  
• 实现了绝大多数SQL92标准。
  
• 整个数据库存储在一个单一的文件中。
  
• 数据库文件可以在不同字节序的机器之间自由地共享。
  
• 支持最大可达2T的数据库。 (241 字节)
  
• 字符串和BLOB类型的大小最大可达 2G 字节(231字节)。
  
• 小的代码： 完整配置的少于250KB，忽略一些可选特性的少于150KB。
  
• 在大多数常见操作上比流行的客户/服务器数据库引擎更快。
  
• 简单，易于使用的API。
  
• 内建TCL绑定。 另外提供可用于许多其他语言的绑定。
  
• 具有良好注释的源代码，95%经过测试。
  
• 独立：没有外部依赖。
  
• 源代码位于公共域。 可用于任何用途。
  

　　SQLite用的非常广泛，Web应用也都在用它，PHP5都内置了SQLite的扩展，所以SQLite是桌面轻量级数据库的首选。除了Access和SQLite外，还有Firebird等数据库，我觉得SQLite足够小系统使用了。