Biggy介绍：一个面向文档数据库的类ORM库

在使用关系数据时，有多种轻量级数据库可供选择，如SQLite和SQL Server Compact。但当文档型数据库能够更好地满足需求时，选择余地之小令人吃惊。于是，我们创建了Biggy。

Biggy由Rob Conery发起创建，面向.NET，与Node的NeDB数据库相当。此后，它发展成为一个类ORM库，但遵循文档数据库的准则。表面看来，开发人员使用的似乎是正常的列表。但这些列表是由一个基于文档的存储层提供支持，比如：

• 在磁盘上的JSON文件中（每个记录类型T一个文件）
• 使用内置的JSON数据类型存储在Postgres数据库中
• 使用普通文本存储在SQL Server中

其它存储选项，如MongoDB和Azure Table Storage，目前正在开发之中。

下面是一个例子，在Postgres中新建一个名为“products”的表，并把一条记录存入其中：

var products = new PGList<Product>("tekpub", "products");
var newProduct = new Product();
//添加到表中
products.Add(newProduct);

由于所有记录的副本都存储在内存中，所以可以完全在内存中使用正常的LINQ查询。但如果需要更强大一点的功能，则可以针对特定的行启用全文搜索。

要实现这一点，开发人员需要将FullText特性应用到他想索引的属性上。这会在表创建的时候“将该列中的文本分离出来”，以便单独对它进行索引。此后，就可以在它上面进行全文搜索。

应用场景

显然，开发人员不应该使用这样一个东西将整个数据库保存在内存中。它主要用于Rob Conery所说的“输入数据”。这类数据很少发生变化，而且需要即时提供，如产品目录。从这种意义上讲，Biggy很像一个可更新的缓存。

Biggy总是实时可用，这是它与缓存的最大不同之一。典型的设计模式是，在应用程序启动的时候，把整个表从磁盘或数据库加载到内存中。在一些基础的基本问题测试中，Biggy能够在1秒钟内从Postgres加载10万条记录。

不过，它确实有一些与缓存相同的局限。例如，如果同时运行一个应用程序的多个实例，那么没有办法使内存中的实例保持同步。

读者可以从GitHub上获取Biggy的源代码，它已经在开源许可证下发布。API还处于不断变化之中，所以还没有在NuGet上提供。

查看英文原文：Introducing Biggy: An ORM-like Library for Document Databases