我真的不相信Object-relational_impedance_mismatch？

Question

http://en.wikipedia.org/wiki/Object-relational_impedance_mismatch

我曾与多个项目合作，他们都使用了以数据库为中心的设计，似乎工作正常。

这似乎是一个新的想法蓬勃发展，现在它似乎很好，但它的价值有待测试或我错了吗？

Answer 1

对象 - 关系不匹配的想法来自于当您尝试使用由关系数据库支持的面向对象编程方法时出现的问题。问题产生于这样一个事实，即对象模型通常包含需要从多个表中分解并重建的对象层次结构，而不是将对象存储为整体。

然而，通常在这一点上出现的论点是，如果你没有发现问题，那么这是你的错，因为你没有做'正确的'面向对象，并且你会发现不匹配的时候你学会了'正确'地面向对象。我们都知道，面向对象是唯一“适当的”发展范式。

哦，等等。

许多系统不适合被建模为面向对象的系统。事实上，对于像Web应用程序这样往往具有整体低复杂性（具有本地化的高复杂性）并且需要高并发性和可伸缩性的事情，使用面向服务和消息传递技术可能是更好的选择。当以这种方式编写应用程序时，您往往会发现没有太多的对象关系不匹配，因为您不使用延迟加载和复杂对象层次结构之类的东西，并且您的对象是不可变的，因此它们不会需要切碎回数据库。

那么是否存在对象关系不匹配？是的，如果您尝试使用关系数据库的面向对象技术。但是，如果其他方法更适合您的应用程序，您可以通过不使用面向对象技术来缓解它。

Answer 2

对象关系阻抗不匹配与关系数据库和面向对象软件模型之间的差异有关。如果您没有看到任何不匹配，那是因为您的代码并没有真正正确地执行OO。

当您开始正确地执行OO并尝试将这些关系映射到RDBMS时，您将理解该问题。

Answer 3

如果您的域模型很简单，并且没有深度继承，您可能永远不会感觉到阻抗不匹配。

作为一个例子，假设类Foo定义了属性foo。 Bar子类Foo，并引入了属性栏。如何在数据库中存储Foos和Bars？

你可以有一个包含字段foo和bar的表Foo ......每个Foo都会满足“bar IS NULL”。但是如果你的子类引入了一大堆属性，那就太浪费了。

所以也许你有两张桌子Foo和Bar。您是否将Foo中的所有列复制到Bar中，以便在一个SELECT中加载整个Bar？或者你是否需要加入Bar来加入一个Bar？

阻抗指的是你必须考虑所有这些关于你如何“粉碎”（使用Greg Beech的术语）一个或多个表格的对象的细节。