对象关系映射，ORM是一个必须在面向对象编程语言中实现并使用关系数据库的所有应用程序中解决的问题。
但是，如果使用结构来映射C中的关系数据库，问题是否相同？函数式编程语言中的元组/记录？或者我错过了一些东西，因为我没有用C或函数式语言编写数据库应用程序。
答案 0 :(得分：6)
至少有趣的是，这种“阻抗不匹配”似乎是人们希望将关系推向对象成语的情况所特有的。
在C语言中，大多数数据库API倾向于将结果集公开为多维数组，而不是结构。因此，人们只是以与数据库中的表中存在的格式相同的格式访问数据 - 现在它作为数据的本地副本而不是“在数据库中”存在是无关紧要的。
大多数功能性RDBMS库将数据库行公开为记录类型，它们在相当深的层次上几乎完美地对应于数据库行。在这种情况下没有“阻抗不匹配”。
关于这个主题的Wikipedia article似乎推测了对象范式特别容易受到这种不匹配的一些原因。
我的信念是，它基本上取决于你总是建立数据的次要表示（即覆盖“对象”）这一事实。在大多数命令式或（非对象）函数式语言中，不太可能构建数据的这种大的，语义上无关的次要表示。如果要在该世界中构建辅助表示，则更有可能是某种抽象。这与我的基本（未经证实的）信念相对应，OOP范式基本上是众所周知的锤子，使每个问题看起来像钉子。
答案 1 :(得分：6)
嗯，是和否。
您所指的是Object-Relational impedance mismatch，即在面向对象的模型和实体关系模型之间传输数据的问题。困难在于在两个模型中构造和存储信息的本质上不同的方式，其中 OO是分层的，而ER是表格。
Object-Relational Mapping是一种尝试解决对象 - 关系阻抗不匹配问题的技术。
术语对象 - 关系阻抗不匹配特定于Object-Oriented和Entity-Relationship模型。然而，“阻抗”一词意味着阻力或难度，因此术语“阻抗不匹配”可能用于表示两个不兼容的数据模型/类型之间的映射的一般问题系统
答案 2 :(得分：3)
ORM中的主要问题不是处理简单的功能，例如将列“x”映射到struct字段“x”。这可以通过几个技巧（宏，代码生成，反射等）来完成。
问题是如何处理OOP功能，如继承，组合，引用，对象唯一性，接口等。继承在这个意义上是一个婊子，因为它的初始实现，因为几个表不是最佳的。
答案 3 :(得分：3)
你有两个阻抗不匹配。
虽然第一个阻抗不匹配可能对所有非OOP语言不起作用，但第二个阻碍所有语言并且可能使用DSL as seen here
来解决