foo bar = new foo();
bar.saveToDatabase();
输给了：
foo bar = new foo();
/* write complicated code to extract stuff from foo */
/* write complicated code to write stuff to database */
相关问题：
可能是因为它们与特定的编程语言耦合性较高。
首先，我不认为它们完全“失败”了。据我所知，仍然有一些公司在使用，但数量已经不多了。
无论如何，可能因为我们想要存储的大部分数据都具有关系性质，所以出现了这个问题。问题在于，虽然是的面向对象数据库更容易集成到面向对象编程语言中，但是关系型数据库更容易定义查询和存储的数据之间的关系。而这通常是复杂的部分。
最近我在我的个人项目中使用了db4o（一种面向对象的数据库），因为它非常快速易用，无需过多细节。
然而，就我所见，这些数据库没有流行起来的主要原因是：
正如Jan Aagaard所指出的那样，最近问题已经以不同的方式得到解决，使程序员即使在针对关系型数据库编程时也能感受到面向对象的特点。
现在有无数应用程序将它们的数据存储在关系数据库中。这些数据是那些公司的命脉。他们共同投资了大量资源来存储、维护和报告这些数据。将这些无价信息转移到基本不同的环境中的成本和风险非常高。
现在考虑ORM工具可以将现代应用程序数据结构映射到传统的关系型模型，你几乎消除了任何迁移到OODBMS的动力。它们提供了一种低风险替代方法，避免了代价高昂的高风险迁移。
因为，尽管ODBMS广告中充斥着有关ORM系统的贬义语言，但让ORM系统完成工作并不难，而且不需要在转向纯ODBMS时承受各种打击。
实际上发生的是，您的第一个代码示例获胜了，只是它恰好位于RDBMS持久性层。
我认为这是因为问题被不同的方式解决了。当你在 Ruby on Rails 或者 LINQ to SQL 中编码时，可能在幕后使用的是关系型数据库，但感觉就像在使用对象一样。
非常主观，但我想到了几个原因：
性能不如关系数据库（或者至少人们的认知是如此）。
再次提到性能 - 关系数据库允许您对数据进行去规范化等操作以进一步提高性能。
遗留支持所有需要访问数据的非面向对象应用程序。
我认为你的答案很大程度上在于“面向对象与关系型数据库”的“我们为什么放弃了对象数据库”的回答中。
就你的例子而言，它不必如此。Linq to SQL实际上是一个相当不错的基本层，可用于DBMS，而Linq to Entities（v2 - v1很糟糕）也将非常酷。Hibernate（N）已经使用RDBMS解决了你现在遇到的问题多年了。
所以，我想对你的回答是，O / R映射器正在达到解决您问题的良好程度，您不需要ODBMS即可获得所需内容。
他们总有一天会成功的。他们是未来。
回顾软件技术的历史，趋势是为了减少复杂性而牺牲性能（Assembly => C => C++ => .NET）。现在只需要30分钟编写的应用程序，在过去的某些日子里需要一个月的时间。
ORMs 是对错误问题的正确答案。目前，它们是选择，因为在没有更好的解决方案的情况下，它们使生活更轻松。但是它们无法处理它们旨在处理的复杂性水平。"问题不能通过创造它们的相同思维水平来解决。" A.E
正如其他人提到的，关系型数据库被广泛使用和依赖，并且替换它们会带来很多风险。看看 SQL 版本之间的间隔以及这些版本与其他 Microsoft 产品之间的主要变化（保守的方法，在这里是必要的）。此外，我还会添加以下项目：
为什么不呢？
我猜他们是为了解决一个没有人遇到的问题，或者是因为没有足够的人愿意为此付费。