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可能不是一个做非常大型的数�
相关文档：
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 ......
前一阵字做项目(嵌入式linux)，由于要保存大量的数据，而且最长要保存30天的时间。本来打算保存到文件中，每次启动应用程序的时候重新解析一遍，可是当数据量很大的时候，就出现效率的问题了。所以最后还是放弃了使用文件的打算，决定使用数据库存取数据。
linux下的数据库也很多，有开源的，也有收费的。对于我们来说，肯 ......
sqlite是
一个非常小巧的跨平台嵌入式数据库，它本身不提供加密功能，不过设计者明显也考虑了加密的方案，我们在源码中可以找到两个预留的加密接
口：sqlite3_key和sqlite3_rekey，可以通过实现这两个接口来达到加密的目的。
如何加密，已经有很多文章描述，可以参考:《
......
