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可能不是一个做非常大型的数据库好选择。在理论上,一个数据库文件文件可以有2TB（241）。日志子系统的内存开销和数据库大小是成比例的。对每个写事务，无论事务实际是写是读那个页，SQLite为每个数据库页维�
相关文档：
我现在要使用SQLite3.0创建一个数据库，然后在数据库中创建一个表格。
首先要引入SQLite3.0的lib库。然后包含头文件#import <sqlite3.h>
【1】打开数据库，如果没有，那么创建一个
sqlite3* database_;
-(BOOL) open{
NSArray *paths = NSSearchPathForDirectoriesInDomai ......
时间:
2009-08-14 21:18:18来源:
网络 作者:
未
知 点击:
214
次
CREATE TRIGGER
sql-statement ::=
......
package com.jiao.sqlite;
import android.app.Activity;
import android.database.Cursor;
import android.os.Bundle;
import android.view.KeyEvent;
import android.view.View;
import android.view.View.OnClickListener;
import android.widget.Button;
import android.widget.EditText;
import android.widg ......
sqlite是
一个非常小巧的跨平台嵌入式数据库，它本身不提供加密功能，不过设计者明显也考虑了加密的方案，我们在源码中可以找到两个预留的加密接
口：sqlite3_key和sqlite3_rekey，可以通过实现这两个接口来达到加密的目的。
如何加密，已经有很多文章描述，可以参考:《
......
