Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

It is always stated that it is hard to store applications objects in relational databases - the object-relational impedance mismatch - and that is why Document databases are better.

However, is there really an impedance mismatch? And object has a key (albeit it may be hidden away by the runtime as a pointer to memory), a set of values, and foreign keys to other objects. Objects are as much made up of tables as it is a document. Neither really fit.

I can see a use for databases to model the data into specific shapes for scenarios in the application - e.g. to speed up database lookup and avoid joins, etc., but won't it be better to keep the data as normalized as possible at the core, and transform as required?

share|improve this question
Did you read the article? It lists the differences quite clearly. And simply saying "but on the lowest levels its all just bits and bytes" doesn't make it go away. There are conceptual differences that are important. Semantics is not a curse word. –  Joachim Sauer Apr 26 '12 at 9:11
-1 "and that is why Document databases are better" - this opinion is not offered in the linked article. Neither do you offer any other evidence for this assertion, nor do you clarify whether you mean specifically for storing objects or for data in general. Further, as pointed out above, the linked article discusses the issue in some detail. –  Mark Bannister Apr 26 '12 at 9:27
The link to the document was added by the editor @gnat not by the orginal poster. –  Lee Atkinson Apr 26 '12 at 9:58
add comment

3 Answers

There is definitely object-relational impedance. I had to deal with this for years on a product that kept its data on a database but was OO when it ran.

As a vastly simplified example, consider three DB tables. Two are just lists, one containing people and one containing jobs. The third is a link between people and jobs, with a column for each. (And all three have lots of columns for lots of subsidiary data.)

In the UI, a user wants to look at the data in terms of a job and the people working on it. A look at the DB, if it's large, is going to be worthless--too much disorganized info. But in the UI, a job object can serve as the basis for good display. Even if the user has a list of a million jobs, he can scroll to the one he wants and see all the relevant info: who's working on it and when and how hard and with what skills, etc.

So on the DB you have 3 tables. In the OO program, you have job objects, people objects and the links between them. The jobs and people lists relate directly to the DB tables, but there is no list of links. The links are part of, or at any rate tied to, the job objects. To create a link table from the OO data, you have to work through all the jobs. To create a proper jobs object, you have to read through the link table and do some awkward rearranging of data.

This is the essence of the impedance. This example is simple in order to be easily understood, but it drastically understates the real-world difficulty in translating between the two concepts.

OO is much faster. It's easier to use once it has been set up. However, it forces a certain organization on the data. If this organization is not done right, or is not adequate, there can be trouble. For instance, in my example the key object is the job. If you want to know what work an individual is doing, it's no good. In this simple example, it is obvious that there needs to be a people object that contains all the work a person is doing, but in a real system the number of possible structures will approach infinity; you have to choose to do that limited number that will let the program do its job.

OO bogs when the random-access aspect of memory becomes slow. OO depends on a lot of direct links between bits of data. How is a large OO database supposed to work? A Document Database makes more sense, but it will either have to really be an OO DB or duplicate vast quantities of data: note that a job object includes people objects, and those people objects include the job object.

Relational data is much slower, but it is without prejudices. A bit of SQL and you can look at the data any way you want. The other, overwhelming, advantage it has is that slow, not-so-random memory--which will bring OO to a halt--doesn't bother it. So if you have terrabytes of data, you want your data stored relationally, not object-orientedly.

So I think we're stuck with relational databases and object-oriented programs and doing a lot of gyrations to get data from the one to the other and back again.

Also: I have recently done some work on a system that uses in-memory relational data. It is very slow, but not so slow as to be seriously annoying (it's not a computer game!) and the original developers, while they had to design a DB, got to skip worrying about an OO design. I considered OO'ing a bit of it, but that meant a lot of programming versus writing just a bit of fancy SQL (LINQ, actually). It clued me in that relational could sometimes compete with OO on its own turf.

It also points out that OO forces organization on the data. If the original developers had known what I needed to do and used OO to do it, the program would have run faster and I could have modified it with a lot less effort. (SQL is tricky.) But if they hadn't OO'ed it they way I needed it done, I'd have been right where I was but without the in-memory relational DB.

Summary: OO and relational are two different things, and converting between them involves impedance--it's a pain. Each has its uses, and I think we're often going to be stuck using both.

share|improve this answer
I don't know about others, but Django can be set up to create those "list of links" objects –  Izkata Feb 22 at 17:23
add comment

I think No.

Impedance mismatch is not an "Objects vs. Relations" problem.

Detail arguments can be found here(PDF file, 11/.pgs).

A problem of impedance mismatch between applications written in OO languages and relational DB is not a problem of discrepancy between object-oriented and relational approaches themselves. Its real causes can be found in habitual implementation of the OO approach. Direct comparison of the two approaches cannot be used as a base for the conclusion that they are discrepant or mismatched. Experimental proof of absence of contradiction between object-oriented paradigm and relational data model is also presented.

share|improve this answer
Hey, thanks for coming back and expanding your answer ;) –  Yannis Rizos Aug 28 '12 at 18:04
add comment

Yes, there is Object-relational impedance. In the early 1980s and 1990s they thought that the solution would be object databases, the most famous of wich is probably the Zope Object Database. Now it is tackled mostry with Object-relational mapping software.

The existance of all these products proves that there are many problems to solve to make the relational world communicate with the object oriented one.

share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.