使用SQLite也有一段时日了，一直想整理出一份比较完整的SQLite指南，可惜时间总是不够。就从这里开始吧，能写多少就写多少。
总特性：
1. SQLite支持事务，满足(ACID)特性：atomic, consistent, isolated, durable。即使在系统crash掉或者掉电的情况下，一样可以恢复。
2. 0配置，不需要安装或者初始化管理即可使用。（不就是嵌入式应用吗？:))
3. 整个数据库存储在跨平台的磁盘文件里头，何谓跨平台，就是说这个文件放到任意平台上，都可以用相同版本的SQLite打开(这个确实强大，目前，即算商用的大型DBMS，其数据文件也没几个是跨平台的，越大越难调头啊...)
4. 支持TB和GB大小的字符串和大对象(BLOB) (写还可以，读呢，只能分片读出来吧....)
5. 常规操作比目前流行的C/S结构的数据库引擎要快(姑且信之)
6. API使用比较简单
7. 源码注释完美，测试覆盖率达100% (后者很难说, 有些bug只有在移动设备上出现过，怎么保证100%? )
8. 使用ANSI-C来开发，使用了TCL绑定。当然也有其它语言的绑定，这些是可选的(详情见：)。
9. 源码以单文件的形式发布，便于用户将其集成到自己的项目当中（这个要赞)
10. 所有源码是以public domain这种license形式发布的，非常宽松，你可以随意修改源码，用于任何目的。
11. 跨平台：Unix(Linux和Mac OS X), OS/2, Windows (Win32 and WinCE)，也很容易移植到其它平台下边。 (这要归功于C语言啊)
12. 随同发布的有一个命令行可执行程序，用于管理SQLite数据库。(shell.c吧)
建议作如下用途：
1. 用作应用程序的文件格式，比如存储xml或者一些特定格式的文件，这样可以避免使用专有的解析器。这种文件至少可以跨平台读取并且具备事务的特性。(用作配置文件，确实不错，存地址簿，小型数据库等，都可以胜任)
2. 用作嵌入设备的数据库. 手机、PDA、MP3等嵌入设备或移动设备。代码量少，能有效的利用内存、磁盘空间和带宽，高可靠性，也不需要DBA来维护。
3. 网站数据库，因为不需要配置什么东西，对于小中型网站来说，用它用网站数据库也无不可（虽然效率有点低）
4. 替代企业级RDBMS.当你想用demo一个系统，又不想装一个庞大的RDBMS，那么SQLite可以满足你的要求，很快就能帮你完成任务。
不能胜任的地方：
1. C/S结构的应用
如果你的应用程序要通过网络访问后端的数据库，应该考虑使用支持C/S结构的数据库，而不是SQLite. SQLite当中的文件锁并不能保持多客户端同时访问数据库的同一部分导致对文件的损坏。
2. 大型网站
缺省页大小是1KB，一个SQLite数据库的大小限制是2TB，即使它能处理更大的数据库，SQLite仍然是只为一个数据库创建一个磁盘文件，很多文件系统本身的限制，使其大小要小于2TB。所以，它不能支持大型网站的数据库存储。
3. 高并发
SQLite使用读/写来锁定整个数据库文件。如果有一个进程正在读取数据库的任何一部分，就会阻止其它进程去写数据库的任何其它部分。类似，如果有一进程正在写操作，其它所有进程就不能读其它任何部分。在多数情况下，这并不是问题。每个应用都会很快完成数据库操作，锁定的时间也不会太长。但是有些应用需要更高的并发能力，这时必须选择其它数据库来达到高并发。
SQLite未实现的SQL特性
SQLite虽然SQL语法比较宽松，但仍有些SQL92中的语法它还不支持。以后也许会慢慢加入相关支持，以加入的可能性从高到低，如下：
1. right outer join和full outer join，目前只支持左外连接(left outer join)
2. 完整的alter table支持，目前只支持rename table和add column，其它的子语句，如drop column, alter column, add constraint 等，并不支持。
3. 完整的触发器支持, for each row触发器是支持，但是for each statement不支持。
4. 写视图操作。SQLite中的视图是只读的。CUD操作是不允许的。但是，可以让你写一个trigger，发出view上的CUD操作。
5. grant和revoke, SQLite只是读写普通的磁盘文件，访问权限受控于操作系统。因此grant 和 revoke常见于C/S结构的数据库。对于嵌入式数据库引擎SQLite而言，没必要存在。
to be cont.
阅读(3204) | 评论(0) | 转发(0) |
