几个小型数据库的比较

几个小型数据库的比较

Access，MSDE 2000，Embedded Firebird，SQLite等都是可以免费再分发（free redistributable）的数据库。

相比而言，MSDE 2000 显著缺点是需要安装，最大优点是和服务器端的 SQL Server 编程模型一致，开发便利。

Access的显著缺点是功能较少，不支持事务等常用功能，最大优点是简单、多数开发者都很熟悉，部署也很方便。

SQLite支持事务，也是一款单文件数据库，比较不足的是 .NET Data Provider 还不是很成熟。

Firebird则同时具有：单文件、部署简单不需安装（只需 XCOPY 两个文件）、支持事务、存储过程、触发器，.NET Data Provider比较稳定成熟等优点。

这个星球上的数据库实在不胜枚举，这里只列一些我接触过的常见的。

可以稍微夸张点说，有交互的应用，起码得用一下数据保存，即便是自定义结构的数据保存，还是最常见的INI、XML等，都可以算是“数据库”，真正点的，如DBase系列、FoxBase、FoxPro、MSAccess、InterBase、MS SQL Server、Oracle、DB2等，这些是商业化的数据库，前面几个只能算是数据库，后面几个是RMDBS（关系型数据库管理系统）。

对应商业化的，有开源的：SQLite、SimpleSQL、Berkely DB、Minosse、Firebird( 前身是是Borland公司的InterBase)、PostgreSQL、MySQL等。

□SQLite：大家可以看我的SQLite系列随笔，C编写的，可以跨操作平台，支持大部分ANSI SQL 92，它是嵌入式的轻量级关系形数据库引擎，只需要一个DLL，体积为250k，数据库也只是一个文件，零配置，便可工作。既然开源，你甚至可以把它嵌入你的程序中。核心开发人员只有一个，最近加入了另外一个，也就是2个人而已，实在佩服，目前发展到3.1.0，相当高效稳定，有开源驱动在上有其 Data

Provider for SQLite ：/projects/adodotnetsqlite/ 。

□SimpleSQL：相对SQLite要大几倍，但也是轻量级的，功能稍微强大一点，C++编写，有OLE、Java等版本。

□Berkely DB：C++编写的大型关系型数据库系统，还额外地支持XML(把XML当成数据库)，号称2百万的安装量，MySQL也只不过号称5百万安装量而已，跨平台。

□Minosse：纯C#编写的大型关系型数据库系统，理想是超越MS SQL Server！最新版本：0.2.0，真难得，纯Java写的看得多了，纯C#的，不是移植别人的，还是第一个，佩服作者：包含C/S和嵌入式版本，并可跨越大部分平台，因为它不用Windows的东西，可以在Mono下编译。

□Firebird：这个东西太牛了，目前有1.5稳定版本已经拥有大量特性，完全支持ANSI SQL92、98等，一些超酷的特性让人疯狂(1.0特性、1.5特性，从这里开始研究)，主要开发人员是一个俄罗斯人，目前开发队伍已经扩大到近100人，有3种模式，单机独立，典型C/S，超级服务器。2.0版本和3.0版本将在近期推出，看完其路线图(2.0、3.0)你就会疯掉。有.NET驱动，目前是1.7beta版。主要特性：

◆A.C.I.D；

◆MGA(任何版本的引擎都可以处理同一数据库记录)；

◆PSQL(存储过程)超级强大，ms sql相对的太次，它啥都能在服务器端实现并推送到客户端成为强大的报表，存储过程；

◆触发器都可以在客户端获取监控追踪；

◆自动只读模式；

◆创新的事务保证绝对不会出错；

◆24*7运行中仍然可以随时备份数据库；

◆统一触发器：任何操作都可以让某表唯一的触发器来总控；

◆大部分语言都可以写plug-in，并直接在存储过程中调用函数；

◆c->c++，更加少的代码但更加快的速度；

◆3种运行模式，甚至可以嵌入式；

◆主流语言都可以调用它；

◆动态sql执行；

◆事务保存点；

□PostgreSQL：POSTGRES数据库的后开源版本，号称拥有任何其他数据库没有的大量新特性，似乎目标是要做超大型的OO关系型数据库系统，目前已经发展到8.0，有.NET驱动，中文官方网站有详细介绍。

□MySQL：这个，不用说了吧？号称全球最受欢迎的开源数据库，但让我奇怪的是，PostgreSQL都有简体中文的支持：包括内核、管理工具、QA等等，在最新版本MySQL中，我却没有发现... ，有.NET驱动，其中MySQL Connector/Net就是原来在上的项目，作者已经加入了MySQL团队，参看《感慨 20 之开源的前途/钱图？（１数据库）》。

======================================================

最近在学习 Firebird Embeded Database。作为一款单文件型小型数据库，Firebird 具有很多吸引人的特征，比如支持事务、支持存储过程、触发器等，而且 Embeded 版本的 Firebird 在 .NET 开发中只需要拷贝两个文件：一个 （非托管但不需要注册的动态链接库）和一个

Data Provider 的 。这些特征都非常适合那些需要在客户端存储一些数据，但又不想安装数据库（比如MSDE）软件的情形。

据称，在国外，需要使用客户端数据库的情况中，有30%左右的开发者选择Access，有30%的开发者选择MSDE 2000，有30%的开发者选择Embedded Firebird，剩余10%选择其他小型数据库，如SQLite，MySQL 等。

上面所说的Access，MSDE 2000，Embedded Firebird，SQLite等都是可以免费再分发（free redistributable）的数据库。相比而言，MSDE 2000

显著缺点是需要安装，最大优点是和服务器端的 SQL Server 编程模型一致，开发便利。Access的显著缺点是功能较少，不支持事务等常用功能，最大优点是简单、多数开发者都很熟悉，部署也很方便。SQLite支持事务，也是一款单文件数据库，比较不足的是 .NET Data Provider 还不是很成熟。Firebird则同时具有：单文件、部署简单不需安装（只需 XCOPY 两个文件）、支持事务、存储过程、触发器，.NET Data Provider比较稳定成熟等优点。

Firebird 本身有SuperServer和Embedded版本之分，后者只能本机访问，不接受TCP连接。对于开发者而言，从Embedded数据库切换到SuperServer，只需更改数据库连接串中的ServerType值就行。

但是，在你正式决定使用?Firebird 之前，请你注意下面这个 known issue（已知问题）： Firebird 数据库文件不能放置在含有中文等字符的路径中。Firebird 的文件名不可以用中文字符，所在路径的任何部分如果含有中文字符，都将无法访问到数据库。举个例子，中文Windows桌面所在的目录一般是“C:Documents and Settings用户名桌面”，如果数据库文件放置在桌面上，就无法访问到。当然，Firebird 内部是可以存储中文字符的，因为它支持 GB2312 和 UNICODE 等字符集。

我已向 Firebird 开发者报告了这个 BUG，希望能早日解决这个 BUG。

需要注意一点，连接串中的 Database 地址如果使用相对路径，请一定注意这个相对路径是相对于 所在目录的。

小型数据库的选择(轻量级数据库)

一直使用Sql Server开发，没有用过Access之外其它的DB。最近正想做个小型工具，这种小东西当然不可能用Sql Server数据库啦，可又不想用Access，于是想起在Blog中看到关于小型数据库的文章，收集如下资料：

据称，在国外，需要使用客户端数据库的情况中，有30%左右的开发者选择Access，有30%的开发者选择MSDE 2000，有30%的开发者选择Embedded Firebird，剩余10%选择其他小型数据库，如SQLite，MySQL 等。

引用

Embedded Firebird DB 简介

最近在学习 Firebird Embeded Database。作为一款单文件型小型数据库，Firebird 具有很多吸引人的特征，比如支持事务、支持存储过程、触发器等，而且 Embeded 版本的 Firebird 在 .NET 开发中只需要拷贝两个文件：一个 （非托管但不需要注册的动态链接库）和一个

Data Provider 的 。这些特征都非常适合那些需要在客户端存储一些数据，但又不想安装数据库（比如MSDE）软件的情形。

据称，在国外，需要使用客户端数据库的情况中，有30%左右的开发者选择Access，有30%的开发者选择MSDE 2000，有30%的开发者选择Embedded

Firebird，剩余10%选择其他小型数据库，如SQLite，MySQL 等。

上面所说的Access，MSDE 2000，Embedded Firebird，SQLite等都是可以免费再分发（free redistributable）的数据库。相比而言，MSDE 2000 显著缺点是需要安装，最大优点是和服务器端的 SQL Server 编程模型一致，开发便利。Access的显著缺点是功能较少，不支持事务等常用功能，最大优点是简单、多数开发者都很熟悉，部署也很方便。SQLite支持事务，也是一款单文件数据库，比较不足的是 .NET Data Provider 还不是很成熟。Firebird则同时具有：单文件、部署简单不需安装（只需 XCOPY 两个文件）、支持事务、存储过程、触发器，.NET Data Provider比较稳定成熟等优点。

Firebird 本身有SuperServer和Embedded版本之分，后者只能本机访问，不接受TCP连接。对于开发者而言，从Embedded数据库切换到SuperServer，只需更改数据库连接串中的ServerType值就行。

但是，在你正式决定使用?Firebird 之前，请你注意下面这个 known issue（已知问题）： Firebird 数据库文件不能放置在含有中文等字符的路径中。Firebird 的文件名不可以用中文字符，所在路径的任何部分如果含有中文字符，都将无法访问到数据库。举个例子，中文Windows桌面所在的目录一般是“C:Documents and Settings用户名桌面”，如果数据库文件放置在桌面上，就无法访问到。当然，Firebird 内部是可以存储中文字符的，因为它支持 GB2312 和 UNICODE 等字符集。

我已向 Firebird 开发者报告了这个 BUG，希望能早日解决这个 BUG。

需要注意一点，连接串中的 Database 地址如果使用相对路径，请一定注意这个相对路径是相对于 所在目录的。

-------------------------

Sqlite中文资料

介绍

这是嵌入式SQL数据库引擎SQLite（SQLite Embeddable SQL Database Engine）的一个扩展。SQLite是一个实现嵌入式SQL数据库引擎的 C语言库（C library）。用SQLite连接的程序可以使用SQL数据库，但不需要运行一个单独的关系型数据库管理系统进程（separate RDBMS process）。

SQLite不是一个用于连接到大型数据库服务器（big database server）的客户端库（client library）。SQLite是一个服务器。SQLite直接读写（reads and

writes directly）在硬盘上的数据库文件。

注：更多关于SQLite的资料请查看SQLite的网站（[url]/[/url]）。

安装

请阅读在安装包里的 INSTALL 文件。或者使用PEAR installer with "pear install sqlite"。SQLite已经内置了，你不需要安装任何附加的软件（additional

software）。

Windows users可以下载SQLite扩展DLL（php_）。

需求

为了可以使用那些函数，你必须编译带上SQLite支持PHP（compile PHP with SQLite support），或者在你的加载SQLite扩展。

资源类型

有两个在SQLite界面（the SQLite Interface）可用的资源。第一个是数据库连接（the database connection），第二是计算结果设置（the result set）。

预定义常量

函数sqlite_fetch_array()和sqlite_current()使用一个常量表示不同的返回类型。下面的常量（表格 1.）已经被定义：

表格 1. SQLite 常量

常量名 意义

SQLITE_ASSOC Columns are returned into the array having the fieldname as the array index.

SQLITE_BOTH Columns are returned into the array having both a numerical index and the fieldname as the array index.

SQLITE_NUM Columns are returned into the array having a numerical index to the fields. This index starts with 0, the first field in the result.

运行时配置

这些函数的行为受到全局配置文件 的影响。

表格 2. SQLite Configuration Options

Name Default Changeable

_case 0 PHP_INI_ALL

For further details and definition of the PHP_INI_* constants see ini_set().

以下是该配置选项的简要解释。

_case int

Whether to use mixed case (0), upper case (1) or lower case (2) hash indexes.

This option is primarily useful when you need compatibility with other database systems, where the names of the columns are always returned as uppercase or

lowercase, regardless of the case of the actual field names in the database schema.

The SQLite library returns the column names in their natural case (that matches the case you used in your schema). When _case is set to 0 the

natural case will be preserved. When it is set to 1 or 2, PHP will apply case folding on the hash keys to upper- or lower-case the keys, respectively.

Use of this option incurs a slight performance penalty, but is MUCH faster than performing the case folding yourself using PHP script.

目录

sqlite_array_query —— 发送一条 SQL 查询，并返回一个数组。

sqlite_busy_timeout —— 设置超时时间（busy timeout duration），或者频繁的用户失去权限（disable busy handlers）。

sqlite_changes —— 返回被最新的SQL 查询（changed by the most recent SQL statement）改变的行数。

sqlite_close —— 关闭一个打开的SQLite数据库。

sqlite_column —— 在当前的行中取得一列（a column from the current row of a result set）。

sqlite_create_aggregate —— Register an aggregating UDF for use in SQL statements。

sqlite_create_function —— Registers a "regular" User Defined Function for use in SQL statements。

sqlite_current —— 在返回的数组中取得当前的行（the current row from a result set as an array）。

sqlite_error_string —— 返回错误代码的原始描述（the textual description of an error code）。

sqlite_escape_string —— 释放一个用于查询的字符串（Escapes a string for use as a query parameter）。

sqlite_fetch_array —— 取得下一行并设置成一个数组（the next row from a result set as an array）。

sqlite_fetch_single —— 取得第一列并设置成一个字符串（Fetches the first column of a result set as a string）。

sqlite_fetch_string —— sqlite_fetch_single()的别名。

sqlite_field_name —— 取得结果中指定字段的字段名。

sqlite_has_more —— 返回是否有更多可用的行（whether or not more rows are available）。

sqlite_last_error —— 返回数据库的最新的错误代码（the error code of the last error for a database）。

sqlite_last_insert_rowid —— 返回最新插入的行的行号（the most recently inserted row）。

sqlite_libencoding —— 返回SQLite库（SQLite library）的编码（encoding）。

sqlite_libversion —— 返回SQLite库（SQLite library）的版本。

sqlite_next —— 返回下一行的行号。

sqlite_num_fields —— 取得结果集中字段的数目。

sqlite_num_rows —— 取得结果集中行的数目。

sqlite_open —— 打开一个SQLite数据库。如果文件不存在则尝试创建之。

sqlite_popen —— 用永久连接的方式打开一个SQLite数据库。如果文件不存在则尝试创建之。

sqlite_query —— 发送一条 SQL 查询，并返回一个结果句柄（a result handle）。

sqlite_rewind —— 倒回第一行（Seek to the first row number）。

sqlite_seek —— 在缓存结果中查找特定的行号（Seek to a particular row number of a buffered result set）。

sqlite_udf_decode_binary —— Decode binary data passed as parameters to an UDF。

sqlite_udf_encode_binary —— Encode binary data before returning it from an UDF。

sqlite_unbuffered_query —— 发送一条 SQL 查询，并不获取和缓存结果的行。

关于Sqlite的问答

为什么选择 SQLite 来捆绑而不用其它数据库？恐怕 PHP 想把 ASP 赶下台了。

对于 PHP 所开发的留言本，整站等程序，为什么使用率比 ASP 低呢？很大原因是数据库的安装，对于一般用户，安装一个 MySQL 数据库相对比较难的，而 Access 则只需要修改数据库路径即可，数据库和站点文件放在一起，非常方便。现在好了，PHP5 将 SQLite 捆绑了，相信以后会出很多相关的应用程序，而这些应用程序的数据库安装相信可以和 ASP 媲美，速度又比 MySQL 快上 1-2 倍（官方的数据），存储量又不是问题（最大可超过 2TB－2000GB，官方数据）。只是对于并发访问我比较担心，还没有测试过不知道如何。呵呵，但是相信这是 PHP 的明智选择，即使服务器不支持 SQLite ，也可以通过加载 php_ 来实现 SQLite 的支持。恩，为什么没有早点想到使用它呢？恐怕是有以下几点原因：

1.当初还不健壮－－即使现在也不知道是不是健壮，代码就那么几百K，呵呵，和 MySQL 对比起来„„

2.感觉好像有点文件系统的味道，就一个数据库文件包含了所有数据„„

3.不支持表的无损修改，也就是说不支持 ALTER TABLE ，这恐怕带来了不少麻烦。改变数据表结构就要重建表，不过有其他方法解决。

4.只支持 left join ，不过差不多够用了，对小型程序来说。

5.优化数据表恐怕比较麻烦。

优点还是很多的，我看了下：

1.安装方便

2.支持大量数据

3.支持大部分SQL

4.弱数据类型

5.速度快（没有测试，官方说法）

6.体积小

7.具备 Command 窗口，下载一个 文件即可对数据库进行命令行操作，和 MySQL 差不多的样子，不过显然不如 MySQL 友好和强大。

8.完全公开的源代码和版权

其他想到再说，感觉 SQLite 很不错的，PEAR 已经提供扩展类支持了。有兴趣下载了看看。

翻译了一部分 FAQ， 英语水平差，可能不准确，翻译得很累，有兴趣的帮忙翻译几段。

常见问答（FAQ）

（最后更新：2004/03/20 15:34:56）

[url]/[/url]

(1) 如何创建自增字段？

(2) SQLite 支持哪些数据类型？

(3) 为什么能向 SQLite 数据库的整型字段中插入字符串？

(4) 为什么 SQLite 认为表达式 '0'=='00' 为真？

(5) 为什么 SQLite 不允许在同一张表里使用 '0' 和 '0.0' 作为两个不同的行的主键？

(6) 为什么不能在 Linux box 中读取在 SparcStation 中创建的 SQLite 数据库？

(7) 多个应用程序或者同一个应用程序的多个例程能同时存取同一个数据库文件吗？

(8) Is SQLite threadsafe?

(9) 如何列出一个 SQLite 数据库中的所有的表/索引？

(10) 有对 SQLite 数据库的任何已知的大小的限制吗？

(11) 在 SQLite 中 VARCHAR 的最大长度是多少？

(12) SQLite 是否支持 BLOB 类型？

(13) 如何从一个已存在的 SQLite 数据表中添加/删除字段？

(14) 我删除了很多数据但是数据库文件并没有减小，是不是 Bug？

(15) 是否能将 SQLite 用于商业用途而不用交版税？

--------------------------------------------------------------------------------

(1) 如何创建自增字段？

简单的回答：一个声明为 INTEGER PRIMARY KEY 的字段将自动增加。

这里是详细的答案： 从 SQLite 的 2.3.4 版本开始，如果你将一个表中的一个字段声明为 INTEGER PRIMARY KEY，那么无论你何时向该表的该字段插入一个 NULL 值，这个 NULL 值将自动被更换为比表中该字段所有行的最大值大 1 的整数；如果表为空，那么将被更换为 1。比如，假设你有这样的一张数据表:

CREATE TABLE t1(

a INTEGER PRIMARY KEY,

b INTEGER

);

在这张数据表里，声明

INSERT INTO t1 valueS(NULL,123);

在逻辑意义上等价于：

INSERT INTO t1 valueS((SELECT max(a) FROM t1)+1,123);

至于 SQLite 的 2.2.0 到 2.3.3 版本，如果你向一个 INTEGER PRIMARY KEY 字段插入 NULL 值, 它将被替换为一个唯一的整数，但它是个半随机的整数。通过这种方式产生的唯一键将不是连续的。而 SQLite 的 2.3.4 及其以后版本，唯一键将是连续的直到其最大值超过 2147483647。这是 32 位整型的最大值因而不能继续增加。因此在 SQLite 的 2.3.3 及其早期版本，并发的插入尝试将返回一个半随机的键生成算法。

从 2.2.3 版本开始，一个新的名为 sqlite_last_insert_rowid() 的 API 函数将为最近的插入操作返回一个整型键。详细资料请查看 API 手册

--------------------------------------------------------------------------------

(2) SQLite 支持哪些数据类型？

SQLite 是弱类型的。所有数据以无终止的字符串存储。在 CREATE TABLE 中，字段名后面的数据类型信息将被忽略（大部分），你可以往任何字段插入你想要的数据类型，而不用管那个字段被声明为什么类型。

这个规则的一个例外是字段为 INTEGER PRIMARY KEY 类型。这样的字段强制一个整型。往 INTEGER PRIMARY KEY 字段插入任何非整型数据将产生一个错误。

这是一个在 SQLite 的数据类型 中更深入解释这一概念的页面。

--------------------------------------------------------------------------------

(3) 为什么能向 SQLite 数据库的整型字段中插入字符串？

这是一个特点,不是错误。SQLite 是弱类型的。任何数据都能够插入任何字段中。你可以往整型字段中插入任意长度的字符串，或者往布尔字段中插入浮点数，或者往字符字段中插入日期。在 CREATE TABLE 命令中你指定给这个字段的数据类型不会限制插入这个字段的数据。所有的字段可以插入任意长度的字符串。（有一个例外：以 INTEGER PRIMARY KEY 为类型的字段只允许整数。如果你尝试往一个 INTEGER PRIMARY KEY 字段插入非整型数据，将产生一个错误。）

然而数据类型是影响值的比较的。因为在一个数字类型（比如 "integer"）字段中，任何字符串在进行比较和排序时是被看成处理成数值的数字。考虑这两个命令序列：

CREATE TABLE t1(a INTEGER UNIQUE); CREATE TABLE t2(b TEXT UNIQUE);

INSERT INTO t1 valueS('0'); INSERT INTO t2 valueS(0);

INSERT INTO t1 valueS('0.0'); INSERT INTO t2 valueS(0.0);

在左边的序列中，第二条插入语句将失败。这种情况下，当字符串 '0' 和 '0.0' 插入一个数字类型字段中时将被处理成数字而 0==0.0 违反了唯一性约束。但是右边序列中的第二条插入语句正常执行。这种情况下，常量 0 和 0.0 被处理成字符串意味着它们是截然不同的。

这是一个在 SQLite 的数据类型 中更深入解释这一概念的页面。

--------------------------------------------------------------------------------

(4) 为什么 SQLite 认为表达式 '0'=='00' 为真？

在 2.7.0 之后，表达式不成立。

但是如果两个值之一在一个数字类型字段中比较，另一个将被转化为数字而不是字符串，而且结果成立。例如：

CREATE TABLE t3(a INTEGER, b TEXT);

INSERT INTO t3 valueS(0,0);

SELECT count(*) FROM t3 WHERE a=='00';

上面序列中的 SELECT 语句返回 1。字段 "a" 是数字类型所以在 WHERE 子句中字符串 '00' 被转换成一个数字作为和 'a' 的比较。0==00 所以这个测试返回 TRUE。现在考虑一个不同的 SELECT 语句：

SELECT count(*) FROM t3 WHERE b=='00';

在这种情况下答案是 0。'b' 是一个 text 字段，文本不匹配 '00'。'0'!='00' 因此 WHERE 子句返回 FALSE 而返回行数为 0。

这是一个在 SQLite 的数据类型 中更深入解释这一概念的页面。

--------------------------------------------------------------------------------

(5) 为什么 SQLite 不允许在同一张表里使用 '0' 和 '0.0' 作为两个不同的行的主键？

你的主键必定是数字类型。将数据类型改成 TEXT 后即可正常运行。

每一行必须有一个唯一的主键。作为一个数字类型的字段，SQLite 认为 '0' 和 '0.0' 的值是相同的，因为他们在数字上的比较是相等的（看前面的问题）因此值不是唯一的。

--------------------------------------------------------------------------------

(6) 为什么不能在 Linux box 中读取在 SparcStation 中创建的 SQLite 数据库？

你需要升级你的 SQLite 库到 2.6.3 或更新版本。

你的 linux box 上的 x86 处理器是 little-endian （意味着整数中的最低位的字节排在前面），但是 Sparc 是 big-endian （最高位的字节排在前面）。在 SQLite 低于 2.6.3 版本的时候，创建于 little-endian 体系中的 SQLite 数据库不能运行于 big-endian 的机器上。从 2.6.3 版本开始，SQLite 应该能够读写数据库文件而不管创建数据库的机器的字节顺序如何。

--------------------------------------------------------------------------------

(7) 多个应用程序或者同一个应用程序的多个例程能同时存取同一个数据库文件吗？

多个程序能够在同一时间打开同一个数据库，能够同时执行 SELECT 命令。但是一次只能有一个进程改变数据库。

Win95/98/ME 操作系统缺乏读/写锁定支持。在 2.7.0 版本之前，这意味着在 Windows 下你一次只能对数据库做单一的读处理。这个问题在 2.7.0 版本中已经通过一个 Windows 下的用户空间读写概率统计策略（implementing a user-space probabilistic reader/writer locking strategy）Windows 现在和

UNIX 一样允许多重的读操作。

The locking mechanism used to control simultaneous access might not work correctly if the database file is kept on an NFS filesystem. This is because file

locking is broken on some NFS implementations. You should avoid putting SQLite database files on NFS if multiple processes might try to access the file at

the same time. On Windows, Microsoft's documentation says that locking may not work under FAT filesystems if you are not running the daemon.

People who have a lot of experience with Windows tell me that file locking of network files is very buggy and is not dependable. If what they say is true,

sharing an SQLite ourse-grained. SQLite locks the entire database. Big database servers (PostgreSQL, Oracle, etc.) generally have finer grained locking, such

as locking on a single table or a single row within a table. If you have a massively parallel database application, you should consider using a big database

server instead of SQLite.

database between two or more Windows machines might cause unexpected problems.

Locking in SQLite is very c

When SQLite tries to access a file that is locked by another process, the default behavior is to return SQLITE_BUSY. You can adjust this behavior from C code

using the sqlite_busy_handler() or sqlite_busy_timeout() API functions. See the API documentation for details.

If two or more processes have the same database open and one process creates a new table or index, the other processes might not be able to see the new table

right away. You might have to get the other processes to close and reopen their connection to the database before they will be able to see the new table.

--------------------------------------------------------------------------------

(8) Is SQLite threadsafe?

Yes. Sometimes. In order to be thread-safe, SQLite must be compiled with the THREADSAFE preprocessor macro set to 1. In the default distribution, the

windows binaries are compiled to be threadsafe but the linux binaries are not. If you want to change this, you'll have to recompile.

"Threadsafe" in the previous paragraph means that two or more threads can run SQLite at the same time on different "sqlite" structures returned from separate

calls to sqlite_open(). It is never safe to use the same sqlite structure pointer simultaneously in two or more threads.

Note that if two or more threads have the same database open and one thread creates a new table or index, the other threads might not be able to see the new

table right away. You might have to get the other threads to close and reopen their connection to the database before they will be able to see the new table.

Under UNIX, you should not carry an open SQLite database across a fork() system call into the child process. Problems will result if you do.

--------------------------------------------------------------------------------

(9) 如何列出一个 SQLite 数据库中的所有的表/索引？

If you are running the sqlite command-line access program you can type ".tables" to get a list of all tables. Or you can type ".schema" to see the complete

database schema including all tables and indices. Either of these commands can be followed by a LIKE pattern that will restrict the tables that are displayed.

From within a C/C++ program (or a script using Tcl/Ruby/Perl/Python bindings) you can get access to table and index names by doing a SELECT on a special

table named "SQLITE_MASTER". Every SQLite database has an SQLITE_MASTER table that defines the schema for the database. The SQLITE_MASTER

table looks like this:

CREATE TABLE sqlite_master (

type TEXT,

name TEXT,

tbl_name TEXT,

rootpage INTEGER,

sql TEXT

);

For tables, the type field will always be 'table' and the name field will be the name of the table. So to get a list of all tables in the database, use the following

SELECT command:

SELECT name FROM sqlite_master

WHERE type='table'

ORDER BY name;

For indices, type is equal to 'index', name is the name of the index and tbl_name is the name of the table to which the index belongs. For both tables and

indices, the sql field is the text of the original CREATE TABLE or CREATE INDEX statement that created the table or index. For automatically created

indices (used to implement the PRIMARY KEY or UNIQUE constraints) the sql field is NULL.

The SQLITE_MASTER table is read-only. You cannot change this table using UPDATE, INSERT, or DELETE. The table is automatically updated by

CREATE TABLE, CREATE INDEX, DROP TABLE, and DROP INDEX commands.

Temporary tables do not appear in the SQLITE_MASTER table. Temporary tables and their indices and triggers occur in another special table named

SQLITE_TEMP_MASTER. SQLITE_TEMP_MASTER works just like SQLITE_MASTER except that it is only visible to the application that created the

temporary tables. To get a list of all tables, both permanent and temporary, one can use a command similar to the following:

SELECT name FROM

(SELECT * FROM sqlite_master UNION ALL

SELECT * FROM sqlite_temp_master)

WHERE type='table'

ORDER BY name

--------------------------------------------------------------------------------

(10) 有对 SQLite 数据库的任何已知的大小的限制吗？

As of version 2.7.4, SQLite can handle databases up to 2^41 bytes (2 terabytes) in size on both Windows and Unix. Older version of SQLite were limited to

databases of 2^31 bytes (2 gigabytes).

SQLite arbitrarily limits the amount of data in one row to 1 megabyte. There is a single #define in the source code that can be changed to raise this limit as

high as 16 megabytes if desired.

There is a theoretical limit of about 2^32 (4 billion) rows in a single table, but this limit has never been tested.

There is also a theoretical limit of about 2^32 tables and indices.

The name and "CREATE TABLE" statement for a table must fit entirely within a 1-megabyte row of the SQLITE_MASTER table. Other than this, there are no

constraints on the length of the name of a table, or on the number of columns, etc. Indices are similarly unconstrained.

The names of tables, indices, view, triggers, and columns can be as long as desired. However, the names of SQL functions (as created by the

sqlite_create_function() API) may not exceed 255 characters in length.

--------------------------------------------------------------------------------

(11) 在 SQLite 中 VARCHAR 的最大长度是多少？

Remember, SQLite is typeless. A VARCHAR column can hold as much data as any other column. The total amount of data in a single row of the database is

limited to 1 megabyte. You can increase this limit to 16 megabytes, if you need to, by adjusting a single #define in the source tree and recompiling.

For maximum speed and space efficiency, you should try to keep the amount of data in a single row below about 230 bytes.

--------------------------------------------------------------------------------

(12) SQLite 是否支持 BLOB 类型？

You can declare a table column to be of type "BLOB" but it will still only store null-terminated strings. This is because the only way to insert information into

an SQLite database is using an INSERT SQL statement, and you can not include binary data in the middle of the ASCII text string of an INSERT statement.

SQLite is 8-bit clean with regard to the data it stores as long as the data does not contain any '000' characters. If you want to store binary data, consider

encoding your data in such a way that it contains no NUL characters and inserting it that way. You might use URL-style encoding: encode NUL as "%00" and

"%" as "%25". Or, you might consider encoding your binary data using base-64. There is a source file named "src/encode.c" in the SQLite distribution that

contains implementations of functions named "sqlite_encode_binary() and sqlite_decode_binary() that can be used for converting binary data to ASCII and

back again, if you like.

--------------------------------------------------------------------------------

(13) 如何从一个已存在的 SQLite 数据表中添加/删除字段？

SQLite does not support the "ALTER TABLE" SQL command. If you what to change the structure of a table, you have to recreate the table. You can save

existing data to a temporary table, drop the old table, create the new table, then copy the data back in from the temporary table.

For example, suppose you have a table named "t1" with columns names "a", "b", and "c" and that you want to delete column "c" from this table. The following

steps illustrate how this could be done:

BEGIN TRANSACTION;

CREATE TEMPORARY TABLE t1_backup(a,B);

INSERT INTO t1_backup SELECT a,b FROM t1;

DROP TABLE t1;

CREATE TABLE t1(a,B);

INSERT INTO t1 SELECT a,b FROM t1_backup;

DROP TABLE t1_backup;

COMMIT;

--------------------------------------------------------------------------------

(14) 我删除了很多数据但是数据库文件并没有减小，是不是 Bug？

不是的。当你从 SQLite 删除数据之后，未使用的磁盘空间被添加到一个内在的“空闲列表”中用于存储你下次插入的数据。磁盘空间并没有丢失，但是也不向操作系统返回磁盘空间。

如果你删除了大量的数据且想要减小数据库文件，执行 VACUUM 命令（2.8.1 或更新版本)。VACUUM 命令将重建数据库will reconstruct the

database from scratch. This will leave the database with an empty free-list and a file that is minimal in size. Note, however, that the VACUUM can take some

time to run (around a half second per megabyte on the Linux box where SQLite is developed) and it can use up to twice as much temporary disk space as the

original file while it is running.

--------------------------------------------------------------------------------

(15) 是否能将 SQLite 用于商业用途而不用交版税？

可以。SQLite 是公开的。代码的任何部分都没有声明所有权。你可以用它来做你想要的任何事情