OEA 2.11 支持单机版数据库 - SQLite与SQLCE对比

在 OEA 平台 设计中，需要支持多种数据库，这至少包括了 SqlServer、Oracle、一个单机文件数据库。而之前对于这一块，我们一直没有实现，只是预留了许多接口。昨天花费了一天的时间，让 OEA 支持了本地数据库 SQLCE。

为什么要支持本地数据库呢？

1. 支持开发简单的本地软件。 
   偶尔需要一些比较小的应用程序，例如“个人计帐管理”、“个人联系方式管理”等。这些简单的软件，如果还让客户装个 SQLServer2008，客户觉得都围绕着。选择使用单机数据库，会让发布变得十分简单、体积也小，做好的程序，打个包发给客户就行了。（当然了，.NET 4.0 还是要装的。） 
   也就是说，用户可以面向个人。
2. 支持单机试用。 
   在开发管理产品时，往往需要把产品给一些客户试用。不用装 SQLServer 的单机版，使得这些客户能够十分简单地试用我们的产品。

OEA 如何支持单机版

配置完成后，运行程序，即在输出目录下建立了 Data 文件夹，并自动生成对应实体的数据库：

这是进销存实例生成的对应的库：

有兴趣的朋友可以在 OEA 2.9 平台发布 中对应的开源地址，使用 SVN 下载最新的源码即可直接运行。（首次启动时，要生成数据库，会需要半分钟左右。）

OEA中单机数据库选型 SQLite vs SQLCE 

接下来，我对 SQLite 进行了一些测试。

主要还是测试这个数据库和 OEA 目前的设计是否有较多的冲突。结果发现果然是太不一样了。首先，OEA 平台的 AutoDb 模块会完全管理数据库，以达到开发人员在平时的开发中忽略数据库的存在。也就是说，这个模块会完成对数据库结构的建立、修改；数据的升级等。可是查了许多关于 SQLLite 的资料，最后得到的结论是：SQLLite 不支持 删除字段，修改字段。其中，还得查询 SQLLite 的数据库结构信息，以支持数据库差异升级，这在 SQLite 中也支持得很有限，只有从一个 sqlite_master 表中查询到数据表的建库SQL，拿出来还得自己解析。其次，在 SQLite 中，外键约束可以被创建，但是却不会被检查。引用完整性都没法保证，查询速度再快有时也没用。而且，象级联删除这类比较普遍的需求也不支持，都需要编写触发器完成，虽然 AutoDb 可以自动编写，但是总感觉太费事了。而 OEA 中聚合对象的删除，目前的设计是在根对象上删除后，自动级联删除整个聚合树，要改的话比较麻烦，所以这一点还是冲突。最后，在界面管理器方面，SQLite 用的主要第三方的软件，有很多，试用了一下，就感觉 SQLiteMgr 还不错，不过用起来并不顺手。

痛苦之余，我再对 SQLCE 进行了研究。

其实目前的 OEA 中已经有使用到 SQLCE 3.5，实现了客户端缓存（详见：OEA中的缓存模块设计）。虽然 SQLCE 3.5 并不支持并发，但是在客户端缓存中没有这个问题。另外，虽然 AutoDB 自动生成并升级数据库，但是在做业务开发的时候，总是要经常去数据库中查询数据。但是 SQLCE 3.5 麻烦的地方就在于没有一个好的界面管理器，不管是 VisualStudio 中集成的功能、还是 SqlServer Management Studio，都不方便使用。这样的话，平时操作起来就会非常麻烦，何谈开发效率。

鉴于此，我又查找了一些最新的 SQLCE 4.0 的资料。比较幸运的是，SQLCE 4.0 现在已经支持并发了，在 Web Matrix 开发 Web 网站时，默认都是使用 SQLCE 4.0 来做数据存储的。而且，它还提供了比较好的界面管理器：SqlCeToolbox，前两天才发布了最新版本，非常好用。（另外，这篇文章中讲了如何使用 SQLCE 开发，还给了 VS 的插件。）其次，SQLCE 4.0中的数据可以无缝地迁移到 SQLServer、SQLAzure 中，这也是非常棒的特性。最后，也是非常重要的，在数据库设计方面，SQLCE 4 基本上和 SQLServer 是保持一致的，支持 主键、外键、自增列、级联删除等。这就使得 我们在 OEA 上，不论是 AutoDB 还是 ORM，支持 SQLCE 都变得比较容易。

有的朋友会说，性能方面，SQLite 可比 SQLCE 快很多。但是其实我个人感觉 SQLCE 的速度也不慢，数据量不是非常大的情况下，应该没有问题。

最后总结一下二者的对比：

最终，经过一天的时间，OEA 成功支持单机数据库。还好有 SQLCE 4，要不就太费劲了！