我偶然看到了db4o OODB数据库,并想知道它与传统的带有关系数据库的堆栈或者像Hibernate/EclipseLink这样的ORM相比有什么不同。应用程序是一个工作流系统,并将随着时间的推移而扩展。不确定像db4o这样的OODB是否适合。我从来没有做过OODB所以我看不出来。有什么建议吗?
发布于 2013-09-20 14:12:37
嗨!下面是一些基于我自己使用DB4O.的经验的信息
如今,对于所谓的OODB(面向对象的数据库)来说,有很多选择。我可以告诉您,与使用常规的RDBMS相比,它是如何工作的,而不是编写这些类似解决方案的列表,因为这是您的实际问题。
你可以在维基百科上读到一些最常用系统的比较:OODB的比较。
如果您使用ORM持久化方法和像NHibernate这样的工具,那么在查询和更新持久化对象之后的数据库时,您会给自己一个更轻松的时间。您可以将像NHibernate这样的工具看作是“混合”解决方案,而对于您提到的纯对象数据库(我已经做了一些自己的工作) Versant / Actian的DB4O,您可以选择直接处理文件系统上的文件,或者选择客户机/服务器之类的解决方案。DB4O支持两者。
最常见的场景可能是前面提到的场景,您将使用本地系统上的一个文件来保存应用程序对象的持久化副本。
DB4O现在作为一种免费的非商业用途产品存在,并且有一个Java和一个.Net版本。它们的工作原理是一样的,根据我的个人经验,它们对任何东西都很好,从简单的2-10 Mega数据库到重在10-12 GB左右的文件.。
根据DB4O开发人员的经验,如果您预期应用程序的数据库需要大于15-16 GigaBytes,则应该考虑其他方法。
DB4O是单线程的,因此需要一个相当快的CPU核心来处理大量事务。但是,考虑到这个明显的限制,它确实运行得很好。
DB4O易于扩展,应该满足对面向对象数据库的大多数需求。
下面是一个简短的例子,它展示了从我自己的项目中获取的一系列自定义对象连接和写入DB是多么容易:(DbPath是一个字符串常量)
public static void StoreObjectsToDb(IEnumerable<SyncObject> syncObjects)
{
using (IObjectContainer container = Db4oEmbedded.OpenFile(DbPath))
{
try
{
foreach (var hdSyncObject in syncObjects)
{
container.Store(hdSyncObject);
Console.WriteLine("Stored Object with HdID {0}\t<-->\tTfsID {1} to database.",hdSyncObject.HdId,hdSyncObject.HdTfsNo);
}
container.Commit();
LogUtility.WriteToLog("Successfully wrote all objects to database.");
}
catch (Exception ex)
{
container.Rollback();
LogUtility.WriteToLog("Could not save objects to database. Rolling back changes...\nError: {0}",ex.Message);
}
finally
{
container.Close();
}
}
}因此,正如您所看到的,有一种非常简单的方法可以创建一个新的数据库并将其填充到对象中,而不需要类定义本身中的任何形式的序列化代码。
许多OODB中都支持许多传统的RDBMS函数,在某些情况下,实现常规SQL数据库的开销远远大于将数据库直接嵌入到源中。
希望这能把事情弄清楚一点。
克里斯
发布于 2019-05-08 14:24:22
对于稍微大一些的应用程序,Gemstone (持久的smalltalk)更适合。这很容易扩展到单台机器支持的最大内存(2/4 TByte?)。在Gemstone中,您通常不会为了获得最佳性能而去变性。
https://stackoverflow.com/questions/18291480
复制相似问题