SQLITE的局限性
SQLite和其他大部分现代SQL数据库在基本设计目标上是不同的，它的目标是简单。SQLite遵循这一目标，即使这样偶尔会导致某些特性实现的低效化。下面列举了SQLite的一些缺陷：
SQL-92特性方面
正如前面提到的，SQLite不支持SQL-92的在很多企业数据库系统中可用的一些特性。
如：
外键约束（可解析的，但非强制）
很多ALTER TABLE特性
一些TRIGGER相关的特性
RIGHT和FULL OUTER JOIN
更新一个VIEW
GRANT和REVOKE
你可以在SQLite的主页上获取最新信息。
http://www.sqlite.org/omitted.html
http://www.sqlite.org/cvstrac/wiki?p=UnsupportedSql
低并发操作
SQLite只支持平面事务；它没有嵌套和营救点能力。嵌套意味着在一个事务中可以有子事务的能力。营救点允许一个事务返回到前面已经到达的状态。它没有能力确保高层次事务的并发。它允许在单个的数据库文件上多个并发的读事务，但是只能有一个排他的写事务。这个局限性意味着如果有事务在读数据库文件的一部分，所有其他的事务将被禁止写该文件的任何一部分。类似的，如果有事务在写数据库文件的一部分，所有其他事务将被禁止读或者写该文件的任何一部分。
应用限制
因为它事务处理的有限并发，SQLite只擅长处理小型的事务。在很多情况下，这不是问题。每个应用迅速的完成它的数据库工作然后继续前进，因此没有一个事务会持有数据库超过多少毫秒。但是在一些应用中，特别是写入密集的，要求更多的并发的事务处理（表或者行级别的而不是数据库级别的）那么你将要为该应用使用其他不同的DBMS。SQLite并不打算成为一个企业DBMS。他最适合于实现，维护和管理的简单性比商业数据库的无尽复杂特性更为重要的情况。
NFS问题
SQLite使用本地文件锁原语来控制事务处理的并发性。如果数据库文件驻留在网络分区上，可能会导致文件锁不能工作。很多的NFS实现被认为在它们的文件锁中是有bug的（在Unix和Windows上）。如果文件锁不能像预计的一样工作，那么就可能会有两个或两个以上的应用程序在同时修改相同数据库的同一部分，导致了数据库的毁坏。因为这个问题的出现是因为位于下层的文件系统的实现的BUG，所以SQLite没有办法阻止它的发生。
另一原因是大多数网络文件系统的连接延时，效果不是很好。在这种环境下，在数据库文件必须要跨网络访问的情况下，实现了客户端-服务器的模型的DBMS会比SQLite更有效。
数据库规模
因为它的开发人员的开发设计选择，SQLite可能不是一个做非常大型的数�
相关文档：
我现在要使用SQLite3.0创建一个数据库，然后在数据库中创建一个表格。
首先要引入SQLite3.0的lib库。然后包含头文件#import <sqlite3.h>
【1】打开数据库，如果没有，那么创建一个
sqlite3* database_;
-(BOOL) open{
NSArray *paths = NSSearchPathForDirectoriesInDomai ......
[编辑本段
]
SQLite简介
SQLite
第一个Alpha版本诞生于2000年5月. 至今已经有10个年头了. SQLite也迎来了一个版本 SQLite 3已经发布.
SQLite是一款轻型的数据库，是遵守ACID的关联式数据库管理系统，它的设计目标是嵌入
式的，而且目前已经在很多嵌入式产品中使用了它，它占用资源非常的低，在嵌入式设备中，� ......
代码很乱，而且没有用到模板，把html代码跟Python代码混在一起了，而且也没有用到web.py本身提供的数据库操作模块，绝对粗超的代码！
学习了很多东西，首先当然是web.py，然后是sqlite，接下来是time模块——看来也唯有不断的实践，才真正能进步！
说实在的，偶学html到现在这么久，还是半桶水，悲剧了！
01&n ......
1 TOP
这是一个大家经常问到的问题，例如在SQLSERVER中可以使用如下语句来取得记录集中的前十条记录：
SELECT TOP 10 * from [index] ORDER BY indexid DESC;
但是这条SQL语句在SQLite中是无法执行的，应该改为：
SELECT * from [index] ORDER BY indexid DESC limit 0,10;
其中limit 0,10表示从第0 ......
