db4o 体验？

我们在大型客户机/服务器项目中运行 DB40 .NET 版本。

我们的经验是，您可以获得比典型关系数据库更好的性能。

但是，您确实必须调整对象才能获得这种性能。例如，如果您有一个包含大量对象的列表，则这些列表的 DB4O 激活速度很慢。有许多方法可以解决这个问题，例如，通过反转关系。

另一个痛苦是激活。从 DB4O 检索或删除对象时，默认情况下，它将激活整个对象树。例如，加载 Foo 将加载 Foo.Bar.Baz.Bat 等，直到没有要加载的内容为止。虽然从编程的角度来看这很好，但性能会减慢对象中嵌套的速度。为了提高性能，您可以告诉 DB4O 要激活多少层深度。如果您有很多对象，这样做非常耗时。

另一个痛苦的领域是文本搜索。DB4O的文本搜索远远慢于SQL全文索引。（他们会在他们的网站上直接告诉你这一点。好消息是，在DB4O之上设置文本搜索引擎很容易。在我们的项目中，我们连接了 Lucene.NET 来索引我们想要的文本字段。

某些 API 似乎不起作用，例如在应用数据库升级时有用的 GetField API。（例如，您已重命名一个属性，并且想要升级数据库中的现有对象，则需要使用这些“反射”API 来查找数据库中的对象。其他 API（如 [Index] 属性）在稳定的 6.4 版本中不起作用，您必须使用 Configure（） 指定索引。Index（“someField”），它不是强类型化的。

我们已经见证了数据库越大，性能就越低。我们现在有一个1GB的数据库，事情仍然很快，但不像我们开始使用一个小型数据库时那么快。

我们发现另一个问题，如果数据库中不再存在该 ID，Db4O.GetByID 将关闭数据库。

我们发现本机查询语法（最自然的，语言集成的查询语法）比不太友好的SODA查询慢得多。因此，与其键入以下内容，不如键入：

// C# syntax for "Find all MyFoos with Bar == 23".
// (Note the Java syntax is more verbose using the Predicate class.)
IList<MyFoo> results = db4o.Query<MyFoo>(input => input.Bar == 23);

而不是那些漂亮的查询代码，你必须有一个丑陋的SODA查询，它是基于字符串的，而不是强类型的。

对于.NET的人来说，他们最近引入了一个LINQ到DB4O的提供程序，它提供了迄今为止最好的语法。但是，性能是否能与丑陋的SODA查询相提并论还有待观察。

DB4O支持相当不错：我们已经在电话上与他们进行了多次交谈，并收到了有用的信息。他们的用户论坛几乎毫无价值，但是，几乎所有问题都没有得到解答。他们的JIRA错误跟踪器受到了很多关注，所以如果你有一个唠叨的错误，把它归档在JIRA上，它通常会得到修复。（我们已经修复了2个错误，另一个以半屁股的方式进行了修补。

如果这一切还没有吓到你，那么让我说，尽管我们遇到了问题，但我们对DB4O非常满意。我们获得的性能已经吹走了我们尝试过的一些O / RM框架。我推荐它。

2015年7月更新请记住，这个答案是在2008年写的。虽然我很欣赏这些赞成票，但从那时起，世界已经发生了变化，这些信息可能不像编写时那样可靠。

大多数本机查询可以并且已经在后台有效地转换为SODA查询，因此这不应该有任何区别。使用NQ当然是首选，因为你仍然处于强类型语言的领域。如果您在让 NQ 使用索引时遇到问题，请随时将您的问题发布到 db4o 论坛，我们将尽力帮助您。

戈兰