Is ORM a problem specific to object oriented programming?

Object-Relational Mapping, ORM is a problem that has to be solved in all applications that is implemented in an object oriented programming language and use a relational database.

But isn't the problem the same if you are using structs to map relational databases in C? And tup开发者_Go百科les/records in a functional programming language? Or am I missing something since I haven't written a database application in C or in a functional language.

---

Well, both yes and no.

What you are referring to is known as the Object-Relational impedance mismatch, that is the problem to transfer data between an Object-Oriented model and a Entity-Relationship model. The difficulty is due to the intrinsically different ways to structure and store information in the two models, where OO is hierarchical while ER is tabular.

Object-Relational Mapping is a technique that attempts to solve the Object-Relational impedance mismatch problem.

The term Object-Relational impedance mismatch is specific to the Object-Oriented and Entity-Relationship models. However the word "impedance" means resistance or difficulty, so the term "impedance mismatch" could potentially be used to express the general problem of mapping between two incompatible data models/type systems.

---

Anecdotally, at least, this "impedance mismatch" appears to be peculiar to situations where one wishes to push relations into an object idiom.

In C most database APIs tend to expose result sets as multi-dimensional arrays, rather than as structs. Consequently, one is simply accessing the data in the same format as it exists in the table(s) in the database -- it's inconsequential that it now exists as a local copy of the data, rather than "in the database".

Most functional RDBMS libraries expose database rows as record types, which correspond at a reasonably deep level to database rows almost perfectly. There is no "impedance mismatch" in this situation.

The Wikipedia article on the subject appears to speculate as to some of the reasons why the object paradigm is particularly susceptible to this mismatch.

My belief is that it essentially hinges on the fact that you are always building a secondary representation of the data (i.e. overlaying "objects"). In most imperative or (non-object) functional languages, one is less likely to build such a large, semantically irrelevant secondary representation of your data. If one is going to build a secondary representation in that world, it is more likely to be an abstraction of some kind. This corresponds to a basic (unsubstantiated) belief of mine that the OOP paradigm is basically the proverbial hammer that makes every problem look like a nail.

---

The main problems in ORM are not to handle the straightforward features, like mapping the column "x" to the struct field "x". That can be done by several tricks (macros, code gen, reflection, and so on).

The problem is how to handle OOP features like inheritance, composition, references, object uniqueness, interfaces, etc. Inheritance is a bitch in this sense, since its naive implementation as several tables is not optimal.

---

You have 2 impedence mismatches.

1. Records to Objects.
2. Your language to SQL queries.

Whilst the first impedence mismatch might not work for all non-OOP languages the second is appearant in all languages and might be solved using DSL's as seen here