嵌入式数据结构
Berkeley DB概述
Berkeley DB是由美国Sleepycat Software公司开发的一套开放源码的嵌入式数据库的程序库（database library），
它为应用程序提供可伸缩的、高性能的、有事务保护功能的数据管理服务。Berkeley DB为数据的存取和管理提供了一组
简洁的函数调用API接口。
它是一个经典的C-library模式的toolkit，为程序员提供广泛丰富的函数集，是为应用程序开发者提供工业级强度的
数据库服务而设计的。其主要特点如下：
嵌入式（Embedded）：它直接链接到应用程序中，与应用程序运行于同样的地址空间中，因此，无论是在网络上不同
计算机之间还是在同一台计算机的不同进程之间，数据库操作并不要求进程间通讯。
Berkeley DB为多种编程语言提供了API接口，其中包括C、C++、Java、Perl、Tcl、Python和PHP，所有的数据库操作
都在程序库内部发生。多个进程，或者同一进程的多个线程可同时使用数据库，有如各自单独使用，底层的服务如加锁、
事务日志、共享缓冲区管理、内存管理等等都由程序库透明地执行。
轻便灵活（Portable）：它可以运行于几乎所有的UNIX和Linux系统及其变种系统、Windows操作系统以及多种嵌入式实
时操作系统之下。它在32位和64位系统上均可运行，已经被好多高端的因特网服务器、台式机、掌上电脑、机顶盒、网络
交换机以及其他一些应用领域所采用。一旦Berkeley DB被链接到应用程序中，终端用户一般根本感觉不到有一个数据库
系统存在。
可伸缩（Scalable）：这一点表现在很多方面。Database library本身是很精简的（少于300KB的文本空间），但它
能够管理规模高达256TB的数据库。它支持高并发度，成千上万个用户可同时操纵同一个数据库。Berkeley DB能以足够小
的空间占用量运行于有严格约束的嵌入式系统，也可以在高端服务器上耗用若干GB的内存和若干TB的磁盘空间。
Berkeley DB在嵌入式应用中比关系数据库和面向对象数据库要好，有以下两点原因：
（1）因为数据库程序库同应用程序在相同的地址空间中运行，所以数据库操作不需要进程间的通讯。在一台机器的
不同进程间或在网络中不同机器间进行进程通讯所花费的开销，要远远大于函数调用的开销；
（2）因为Berkeley DB对所有操作都使用一组API接口，因此不需要对某种查询语言进行解析，也不用生成执行计划，
大大提高了运行效.
BerkeleyDB系统结构
Berkeley DB由五个主要的子系统构成.包括: 存取管理子系统、内存池管理子系统、事务子系统、锁子系统以及日志子系统。
其中存取管理子系统作为Berkeley DB数据库进程包内部核心组件，而其他子系统都存在于Berkeley DB数据库进程包的外部。
每个子系统支持不同的应用级别。
1.数据存取子系统
数据存取（Access Methods）子系统为创建和访问数据库文件提供了多种支持。Berkeley DB提供了以下四种文件存储方法：
哈希文件、B树、定长记录（队列）和变长记录（基于记录号的简单存储方式），应用程序可以从中选择最适合的文件组织结构。
程序员创建表时可以使用任意一种结构，并且可以在同一个应用程序中对不同存储类型的文件进行混合操作。
在没有事务管理的情况下，该子系统中的模块可单独使用，为应用程序提供快速高效的数据存取服务。
数据存取子系统适用于不需事务只需快速格式文件访问的应用。
2.内存池管理子系统
内存池（Memory pool）子系统对Berkeley DB所使用的共享缓冲区进行有效的管理。它允许同时访问数据库的多个进程或者
进程的多个线程共享一个高速缓存，负责将修改后的页写回文件和为新调入的页分配内存空间。
它也可以独立于Berkeley DB系统之外，单独被应用程序使用，为其自己的文件和页分配内存空间。
内存池管理子系统适用于需要灵活的、面向页的、缓冲的共享文件访问的应用。
3.事务子系统
事务（Transaction）子系统为Berkeley DB提供事务管理功能。它允许把一组对数据库的修改看作一个原子单位，
这组操作要么全做，要么全不做。在默认的情况下，系统将提供严格的ACID事务属性，但是应用程序可以选择不使用系统所作的
隔离保证。该子系统使用两段锁技术和先写日志策略来保证数据库数据的正确性和一致性。
它也可以被应用程序单独使用来对其自身的数据更新进行事务保护。事务子系统适用于需要事务保证数据的修改的应用。
4.锁子系统
锁（Locking）子系统为Berkeley DB提供锁机制，为系统提供多用户读取和单用户修改同一对象的共享控制。
数据存取子系统可利用该子系统获得对页或记录的读写权限；事务子系统利用锁机制来实现多个事务的并发控制。
该子系统也可被应用程序单独采用。锁子系统适用于一个灵活的、快速的、可设置的锁管理器。
5.日志子系统
日志（Logging）子系统采用的是先写日志的策略，用于支持事务子系统进行数据恢复，保证数据一致性。
它不大可能被应用程序单独使用，只能作为事务子系统的调用模块。
以上几部分构成了整个Berkeley DB数据库系统。各部分的关系如下图所示：
在这个模型中，应用程序直接调用的是数据存取子系统和事务管理子系统，这两个系统进而调用更下层的内存管理子系统、
锁子系统和日志子系统。
由于几个子系统相对比较独立，所以应用程序在开始的时候可以指定哪些数据管理服务将被使用。可以全部使用，
也可以只用其中的一部分。例如，如果一个应用程序需要支持多用户并发操作，但不需要进行事务管理，那它就可以
只用锁子系统而不用事务。有些应用程序可能需要快速的、单用户、没有事务管理功能的B树存储结构，那么应用程序
可以使锁子系统和事务子系统失效，这样就会减少开销。
BerkeleyDB存储功能概述
Berkeley DB所管理数据的逻辑组织单位是若干个独立或有一定关系的数据库(database)，
每个数据库由若干记录组成，这些记录全都被表示成(key，value)的形式.
如果把一组相关的(key，value)对也看作一个表的话，那么每一个数据库只允许存放一个table，
这一点不同于一般的关系数据库。实际上，在Berkeley DB中所提到的“数据库”，相当于一般关系数据库系统中的表；
而“key/data”对相当于关系数据库系统中的行(rows)；Berkeley DB不提供关系数据库中列直接访问的功能，
而是在“key/data”对中的data项中通过实际应用来封装字段(列)。
在物理组织上，每一个数据库在创建的时候可以由应用程序根据其数据特点来选择一种合适的存储结构。
可供选择的四种文件存储结构分别是：哈希文件、B树、定长记录(队列)和变长记录(基于记录号的简单存储方式)。
一个物理的文件中可以只存放一个单独的数据库，也可以存放若干相关或不相关的数据库，而且这些数据库
可以分别采用除队列之外任意不同的组织方式，以队列组织的数据库只能单独存放于一个文件，不能同其他存储类型混合存放。
一个文件除了受最大文件长度和存储空间的约束之外，理论上可以存储任意多个数据库。
因此系统定位一个数据库通常需要两个参数——“文件名”和“数据库名”，这也是Berkeley DB不同于
一般关系数据库的地方。
Berkeley DB存储系统为应用程序提供了一系列的接口函数，用于对数据库的管理和操作。其中包括：
(1)数据库的创建、打开、关闭、删除、重命名等，以及对数据的检索和增删改操作；
(2)提供一些附加的功能，例如读取数据库状态信息、读取所在文件的信息、读取所在数据库环境的信息、
清空数据库的内容、数据库的同步备份、版本升级、提示出错信息等等；
(3)系统还提供了游标机制，用于存取和访问成组的数据，以及对两个或多个相关数据库进行关联和等值连接操作；
(4)系统还给出了一些接口函数用于对存取策略进行优化配置，比如应用程序可以自己设置B树的排序比较函数、
每页中存放key的最少数目，哈希桶的填充因子、哈希函数、哈希表最大长度，队列的最大长度，数据库存放的字节顺序，
底层存储页的大小，内存分配函数，高速缓存的大小，定长记录的大小和填充位，变长记录所用的分隔符等等。
Firebird DB 简介
Firebird Embeded Database。作为一款单文件型小型数据库，Firebird 具有很多吸引人的特征，比如支持事务、支持存储过程、触发器等，而且 Embeded 版本的 Firebird 在 .NET 开发中只需要拷贝两个文件：一个 fbembed.dll （非托管但不需要注册的动态链接库）和一个 ADO.NET Data Provider 的 FirebirdSql.Data.Firebird.dll。这些特征都非常适合那些需要在客户端存储一些数据，但又不想安装数据库（比如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值就行。
SQLite DB
SQLite的源代码是C，其源代码完全开放。SQLite第一个Alpha版本诞生于2000年5月。今年5月，SQLite又迎来了一个新的里程一SOLite 3。
SQLite有以下特性：支持ACID事务；零配置一无需安装和管理配置；储存在单一磁盘文件中的一个完整的数据库；数据库文件可以在不同字节顺序的机器间自由共享；支持数据库大小至2TB；足够小，全部源码大致3万行c代码，250KB；比目前流行的大多数数据库对数据的操作要快；提供了对事务功能和并发处理的支持，应用Transaction既保证了数据的完整性，也会提高运行速度，因为多条语句一起提交给数据库的速度会比一条一条的提交方式更快；独立，没有额外依赖。SQL语言很大程度上实现了ANSI SQL92标准，特别是支持视图、触发器、事务，支持嵌套SQL
eXtremeDB 内存式实时数据库
eXtremeDB 是美国 McObject 公司的产品。该公司位于华盛顿州，在编译器、实时编程、数据管理及内核级驱动程序方面有 30 多年的从业经验。
McObject 产品包括 eXtremeDB 内存式数据库、 SQL 功能支持 eXtremeSQL 、交易日志支持 eXtremeLog 、高可用性支持 eXtremeHA 及 eXtremeWS 嵌入式 Web Server 等。其中 eXtremeDB 是其基本产品； eXtremeSQL 提供 SQL 支持功能； eXtremeLog 提供交易日志支持功能； eXtremeHA 为 eXtremeDB 提供高可用性功能； eXtremeWS 与 eXtremeDB 无缝集成，使得用户可以通过 Web 方式访问、使用数据库
eXtremeDB 与同类产品不同之处首先在于它不基于任何文件系统。
实时数据库不是一个特别新的概念，主要以管理实时数据为目的。这些实时数据管理系统大多借鉴企业数据库的概念，进行面向实时应用的优化，如通过 RAM Disk 或 Cache 等机制减少对磁盘的访问从而提高数据库的性能。这种优化一定程度上改进了数据库的速度，但由于不是特地为实时数据管理而设计，依然要保留诸如缓存、文件 I/O 操作等机制，对实时性能的提升幅度有限，不能完全满足实际工作的需要，大多数用户还是使用自己设计的数据库管理程序管理实时数据。历史上，为了管理实时数据， McObject 公司经常要进行企业数据库的裁减。由于这样的工作量很大，最终促使 McObject 公司推出了 eXtremeDB 这一专门以实时数据管理为市场的新产品。
eXtremeDB 与同类产品不同之处还在于 eXtremeDB 是内联库结构，而大多数同类产品采用的是 C/S 结构。 C/S 结构管理实时数据的一个不利之处在于由此引入的任务间通信不确定性。而内联库剔除了这种不定性。
作为实时数据库， eXtremeDB 是如何提高其实时性能的？
作为面向实时数据管理的数据库系统， eXtremeDB 通过以下措施提高其实时性能：
根据用户数据特征生成 API ；数据存储在内存中不基于任何文件系统，取消了文件 I/O 操作的开销；省略了 Cache 开销；由于不基于文件系统，系统优化不再以减少文件访问为目的，而是以减少 CPU 开销为目的，因此是更高层次的优化；如同实时操作系统一样，交易赋予优先级，保证关键交易的实时性。
是的， eXtremeDB 是嵌入式数据库。其基本开销可以小到 60K 字节左右；管理实时数据的空间的额外开销只有 20 ％。由于 API 是根据用户数据特征产生的，调用这些 API 就可以使用 eXtremeDB 管理实时数据，因此， eXtremeDB 天然地与用户程序集成在一起。所以， eXtremeDB 是嵌入式数据库。这里，有一点要补充说明一下，有些基于文件系统的数据库由于尺寸可以剪裁，因此，在运行的时候可以在 Flash 或 RAM Disk 上工作。这样的数据库可以说是可嵌入的；而 eXtremeDB 不依赖文件系统、完全嵌入在应用程序中，因此才是真正嵌入式的。
嵌入式系统通常是紧凑系统，即小系统。对于大量实时数据需要管理的情形， eXtremeDB 是否胜任？
这一点要特别指出： eXtremeDB 首先是一个实时数据库，而后才是嵌入式数据库。由于实时数据管理对时间空间效率的要求非常高，完成同样工作的资源要求更少。因此，在资源紧凑型系统中， eXtremeDB 就的优点就显示出来了。所以， eXtremeDB 开销超小并与应用程序天然集成实现嵌入，这并不意味着 eXtremeDB 只能管理小系统中的数据。 eXtremeDB 是嵌入式的，但并不要求应用系统是嵌入式的。应用系统可以是嵌入式系统如手机、家庭网管、机顶盒、数字电视等，也可以是桌面系统或服务器系统如核心路由器、呼叫中心、金融交易系统等。大系统的实时数据管理更是 eXtremeDB 的长处，这一点已经在国内外的实际使用中得到了印证。
mSQL嵌入式数据库
mSQL(mini SQL)是一个单用户数据库管理系统，个人使用免费，商业使用收费。由于它的短小精悍，使其开发的应用系统特别受到互联网用户青睐。mSQL(mini SQL)是一种小型的关系数据库,性能不是太好,对SQL语言的支持也不够完全,但在一些网络数据库应用中是足够了。由于mSQL较简单，在运行简单的SQL语句时速度比MySQL略快，而MySQL在线程和索引上下了功夫,运行复杂的SQL语句时比mSQL,PostgreSQL等都要快一些。MSQL的网址是：http://www.hughes.com.au ，最新版本是2005年5月8日发布的3.7。MSQL的标志是一个鹿。
mSQL的技术特点：
安全性方面,mSQL通过ACL文件设定各主机上各用户的访问权限,缺省是 全部可读/写。mSQL缺乏 ANSI SQL 的大多数特征，它仅仅实现了一个最最少的API，没有事务和参考完整性。mSQL与Lite（一种类似C的脚本语言，与分发一起发行）紧密结合，可以得到一个称为 W3-mSQL的一个网站集成包，它是JDBC、ODBC、Perl和PHP API。
Berkeley DB是由美国Sleepycat Software公司开发的一套开放源码的嵌入式数据库的程序库（database library），
它为应用程序提供可伸缩的、高性能的、有事务保护功能的数据管理服务。Berkeley DB为数据的存取和管理提供了一组
简洁的函数调用API接口。
它是一个经典的C-library模式的toolkit，为程序员提供广泛丰富的函数集，是为应用程序开发者提供工业级强度的
数据库服务而设计的。其主要特点如下：
嵌入式（Embedded）：它直接链接到应用程序中，与应用程序运行于同样的地址空间中，因此，无论是在网络上不同
计算机之间还是在同一台计算机的不同进程之间，数据库操作并不要求进程间通讯。
Berkeley DB为多种编程语言提供了API接口，其中包括C、C++、Java、Perl、Tcl、Python和PHP，所有的数据库操作
都在程序库内部发生。多个进程，或者同一进程的多个线程可同时使用数据库，有如各自单独使用，底层的服务如加锁、
事务日志、共享缓冲区管理、内存管理等等都由程序库透明地执行。
轻便灵活（Portable）：它可以运行于几乎所有的UNIX和Linux系统及其变种系统、Windows操作系统以及多种嵌入式实
时操作系统之下。它在32位和64位系统上均可运行，已经被好多高端的因特网服务器、台式机、掌上电脑、机顶盒、网络
交换机以及其他一些应用领域所采用。一旦Berkeley DB被链接到应用程序中，终端用户一般根本感觉不到有一个数据库
系统存在。
可伸缩（Scalable）：这一点表现在很多方面。Database library本身是很精简的（少于300KB的文本空间），但它
能够管理规模高达256TB的数据库。它支持高并发度，成千上万个用户可同时操纵同一个数据库。Berkeley DB能以足够小
的空间占用量运行于有严格约束的嵌入式系统，也可以在高端服务器上耗用若干GB的内存和若干TB的磁盘空间。
Berkeley DB在嵌入式应用中比关系数据库和面向对象数据库要好，有以下两点原因：
（1）因为数据库程序库同应用程序在相同的地址空间中运行，所以数据库操作不需要进程间的通讯。在一台机器的
不同进程间或在网络中不同机器间进行进程通讯所花费的开销，要远远大于函数调用的开销；
（2）因为Berkeley DB对所有操作都使用一组API接口，因此不需要对某种查询语言进行解析，也不用生成执行计划，
大大提高了运行效.
BerkeleyDB系统结构
Berkeley DB由五个主要的子系统构成.包括: 存取管理子系统、内存池管理子系统、事务子系统、锁子系统以及日志子系统。
其中存取管理子系统作为Berkeley DB数据库进程包内部核心组件，而其他子系统都存在于Berkeley DB数据库进程包的外部。
每个子系统支持不同的应用级别。
1.数据存取子系统
数据存取（Access Methods）子系统为创建和访问数据库文件提供了多种支持。Berkeley DB提供了以下四种文件存储方法：
哈希文件、B树、定长记录（队列）和变长记录（基于记录号的简单存储方式），应用程序可以从中选择最适合的文件组织结构。
程序员创建表时可以使用任意一种结构，并且可以在同一个应用程序中对不同存储类型的文件进行混合操作。
在没有事务管理的情况下，该子系统中的模块可单独使用，为应用程序提供快速高效的数据存取服务。
数据存取子系统适用于不需事务只需快速格式文件访问的应用。
2.内存池管理子系统
内存池（Memory pool）子系统对Berkeley DB所使用的共享缓冲区进行有效的管理。它允许同时访问数据库的多个进程或者
进程的多个线程共享一个高速缓存，负责将修改后的页写回文件和为新调入的页分配内存空间。
它也可以独立于Berkeley DB系统之外，单独被应用程序使用，为其自己的文件和页分配内存空间。
内存池管理子系统适用于需要灵活的、面向页的、缓冲的共享文件访问的应用。
3.事务子系统
事务（Transaction）子系统为Berkeley DB提供事务管理功能。它允许把一组对数据库的修改看作一个原子单位，
这组操作要么全做，要么全不做。在默认的情况下，系统将提供严格的ACID事务属性，但是应用程序可以选择不使用系统所作的
隔离保证。该子系统使用两段锁技术和先写日志策略来保证数据库数据的正确性和一致性。
它也可以被应用程序单独使用来对其自身的数据更新进行事务保护。事务子系统适用于需要事务保证数据的修改的应用。
4.锁子系统
锁（Locking）子系统为Berkeley DB提供锁机制，为系统提供多用户读取和单用户修改同一对象的共享控制。
数据存取子系统可利用该子系统获得对页或记录的读写权限；事务子系统利用锁机制来实现多个事务的并发控制。
该子系统也可被应用程序单独采用。锁子系统适用于一个灵活的、快速的、可设置的锁管理器。
5.日志子系统
日志（Logging）子系统采用的是先写日志的策略，用于支持事务子系统进行数据恢复，保证数据一致性。
它不大可能被应用程序单独使用，只能作为事务子系统的调用模块。
以上几部分构成了整个Berkeley DB数据库系统。各部分的关系如下图所示：
在这个模型中，应用程序直接调用的是数据存取子系统和事务管理子系统，这两个系统进而调用更下层的内存管理子系统、
锁子系统和日志子系统。
由于几个子系统相对比较独立，所以应用程序在开始的时候可以指定哪些数据管理服务将被使用。可以全部使用，
也可以只用其中的一部分。例如，如果一个应用程序需要支持多用户并发操作，但不需要进行事务管理，那它就可以
只用锁子系统而不用事务。有些应用程序可能需要快速的、单用户、没有事务管理功能的B树存储结构，那么应用程序
可以使锁子系统和事务子系统失效，这样就会减少开销。
BerkeleyDB存储功能概述
Berkeley DB所管理数据的逻辑组织单位是若干个独立或有一定关系的数据库(database)，
每个数据库由若干记录组成，这些记录全都被表示成(key，value)的形式.
如果把一组相关的(key，value)对也看作一个表的话，那么每一个数据库只允许存放一个table，
这一点不同于一般的关系数据库。实际上，在Berkeley DB中所提到的“数据库”，相当于一般关系数据库系统中的表；
而“key/data”对相当于关系数据库系统中的行(rows)；Berkeley DB不提供关系数据库中列直接访问的功能，
而是在“key/data”对中的data项中通过实际应用来封装字段(列)。
在物理组织上，每一个数据库在创建的时候可以由应用程序根据其数据特点来选择一种合适的存储结构。
可供选择的四种文件存储结构分别是：哈希文件、B树、定长记录(队列)和变长记录(基于记录号的简单存储方式)。
一个物理的文件中可以只存放一个单独的数据库，也可以存放若干相关或不相关的数据库，而且这些数据库
可以分别采用除队列之外任意不同的组织方式，以队列组织的数据库只能单独存放于一个文件，不能同其他存储类型混合存放。
一个文件除了受最大文件长度和存储空间的约束之外，理论上可以存储任意多个数据库。
因此系统定位一个数据库通常需要两个参数——“文件名”和“数据库名”，这也是Berkeley DB不同于
一般关系数据库的地方。
Berkeley DB存储系统为应用程序提供了一系列的接口函数，用于对数据库的管理和操作。其中包括：
(1)数据库的创建、打开、关闭、删除、重命名等，以及对数据的检索和增删改操作；
(2)提供一些附加的功能，例如读取数据库状态信息、读取所在文件的信息、读取所在数据库环境的信息、
清空数据库的内容、数据库的同步备份、版本升级、提示出错信息等等；
(3)系统还提供了游标机制，用于存取和访问成组的数据，以及对两个或多个相关数据库进行关联和等值连接操作；
(4)系统还给出了一些接口函数用于对存取策略进行优化配置，比如应用程序可以自己设置B树的排序比较函数、
每页中存放key的最少数目，哈希桶的填充因子、哈希函数、哈希表最大长度，队列的最大长度，数据库存放的字节顺序，
底层存储页的大小，内存分配函数，高速缓存的大小，定长记录的大小和填充位，变长记录所用的分隔符等等。
Firebird DB 简介
Firebird Embeded Database。作为一款单文件型小型数据库，Firebird 具有很多吸引人的特征，比如支持事务、支持存储过程、触发器等，而且 Embeded 版本的 Firebird 在 .NET 开发中只需要拷贝两个文件：一个 fbembed.dll （非托管但不需要注册的动态链接库）和一个 ADO.NET Data Provider 的 FirebirdSql.Data.Firebird.dll。这些特征都非常适合那些需要在客户端存储一些数据，但又不想安装数据库（比如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值就行。
SQLite DB
SQLite的源代码是C，其源代码完全开放。SQLite第一个Alpha版本诞生于2000年5月。今年5月，SQLite又迎来了一个新的里程一SOLite 3。
SQLite有以下特性：支持ACID事务；零配置一无需安装和管理配置；储存在单一磁盘文件中的一个完整的数据库；数据库文件可以在不同字节顺序的机器间自由共享；支持数据库大小至2TB；足够小，全部源码大致3万行c代码，250KB；比目前流行的大多数数据库对数据的操作要快；提供了对事务功能和并发处理的支持，应用Transaction既保证了数据的完整性，也会提高运行速度，因为多条语句一起提交给数据库的速度会比一条一条的提交方式更快；独立，没有额外依赖。SQL语言很大程度上实现了ANSI SQL92标准，特别是支持视图、触发器、事务，支持嵌套SQL
eXtremeDB 内存式实时数据库
eXtremeDB 是美国 McObject 公司的产品。该公司位于华盛顿州，在编译器、实时编程、数据管理及内核级驱动程序方面有 30 多年的从业经验。
McObject 产品包括 eXtremeDB 内存式数据库、 SQL 功能支持 eXtremeSQL 、交易日志支持 eXtremeLog 、高可用性支持 eXtremeHA 及 eXtremeWS 嵌入式 Web Server 等。其中 eXtremeDB 是其基本产品； eXtremeSQL 提供 SQL 支持功能； eXtremeLog 提供交易日志支持功能； eXtremeHA 为 eXtremeDB 提供高可用性功能； eXtremeWS 与 eXtremeDB 无缝集成，使得用户可以通过 Web 方式访问、使用数据库
eXtremeDB 与同类产品不同之处首先在于它不基于任何文件系统。
实时数据库不是一个特别新的概念，主要以管理实时数据为目的。这些实时数据管理系统大多借鉴企业数据库的概念，进行面向实时应用的优化，如通过 RAM Disk 或 Cache 等机制减少对磁盘的访问从而提高数据库的性能。这种优化一定程度上改进了数据库的速度，但由于不是特地为实时数据管理而设计，依然要保留诸如缓存、文件 I/O 操作等机制，对实时性能的提升幅度有限，不能完全满足实际工作的需要，大多数用户还是使用自己设计的数据库管理程序管理实时数据。历史上，为了管理实时数据， McObject 公司经常要进行企业数据库的裁减。由于这样的工作量很大，最终促使 McObject 公司推出了 eXtremeDB 这一专门以实时数据管理为市场的新产品。
eXtremeDB 与同类产品不同之处还在于 eXtremeDB 是内联库结构，而大多数同类产品采用的是 C/S 结构。 C/S 结构管理实时数据的一个不利之处在于由此引入的任务间通信不确定性。而内联库剔除了这种不定性。
作为实时数据库， eXtremeDB 是如何提高其实时性能的？
作为面向实时数据管理的数据库系统， eXtremeDB 通过以下措施提高其实时性能：
根据用户数据特征生成 API ；数据存储在内存中不基于任何文件系统，取消了文件 I/O 操作的开销；省略了 Cache 开销；由于不基于文件系统，系统优化不再以减少文件访问为目的，而是以减少 CPU 开销为目的，因此是更高层次的优化；如同实时操作系统一样，交易赋予优先级，保证关键交易的实时性。
是的， eXtremeDB 是嵌入式数据库。其基本开销可以小到 60K 字节左右；管理实时数据的空间的额外开销只有 20 ％。由于 API 是根据用户数据特征产生的，调用这些 API 就可以使用 eXtremeDB 管理实时数据，因此， eXtremeDB 天然地与用户程序集成在一起。所以， eXtremeDB 是嵌入式数据库。这里，有一点要补充说明一下，有些基于文件系统的数据库由于尺寸可以剪裁，因此，在运行的时候可以在 Flash 或 RAM Disk 上工作。这样的数据库可以说是可嵌入的；而 eXtremeDB 不依赖文件系统、完全嵌入在应用程序中，因此才是真正嵌入式的。
嵌入式系统通常是紧凑系统，即小系统。对于大量实时数据需要管理的情形， eXtremeDB 是否胜任？
这一点要特别指出： eXtremeDB 首先是一个实时数据库，而后才是嵌入式数据库。由于实时数据管理对时间空间效率的要求非常高，完成同样工作的资源要求更少。因此，在资源紧凑型系统中， eXtremeDB 就的优点就显示出来了。所以， eXtremeDB 开销超小并与应用程序天然集成实现嵌入，这并不意味着 eXtremeDB 只能管理小系统中的数据。 eXtremeDB 是嵌入式的，但并不要求应用系统是嵌入式的。应用系统可以是嵌入式系统如手机、家庭网管、机顶盒、数字电视等，也可以是桌面系统或服务器系统如核心路由器、呼叫中心、金融交易系统等。大系统的实时数据管理更是 eXtremeDB 的长处，这一点已经在国内外的实际使用中得到了印证。
mSQL嵌入式数据库
mSQL(mini SQL)是一个单用户数据库管理系统，个人使用免费，商业使用收费。由于它的短小精悍，使其开发的应用系统特别受到互联网用户青睐。mSQL(mini SQL)是一种小型的关系数据库,性能不是太好,对SQL语言的支持也不够完全,但在一些网络数据库应用中是足够了。由于mSQL较简单，在运行简单的SQL语句时速度比MySQL略快，而MySQL在线程和索引上下了功夫,运行复杂的SQL语句时比mSQL,PostgreSQL等都要快一些。MSQL的网址是：http://www.hughes.com.au ，最新版本是2005年5月8日发布的3.7。MSQL的标志是一个鹿。
mSQL的技术特点：
安全性方面,mSQL通过ACL文件设定各主机上各用户的访问权限,缺省是 全部可读/写。mSQL缺乏 ANSI SQL 的大多数特征，它仅仅实现了一个最最少的API，没有事务和参考完整性。mSQL与Lite（一种类似C的脚本语言，与分发一起发行）紧密结合，可以得到一个称为 W3-mSQL的一个网站集成包，它是JDBC、ODBC、Perl和PHP API。