I've thought about this a bit, having had to write various ORM layers over the years. My conclusion is that OOP is conceptually built around single "objects" w

I've thought about this a bit, having had to write various ORM layers over the years. My conclusion is that OOP is conceptually built around single "objects" where RDBMSs are built around sets of "objects". The difference in nominal units is some of the basis of the impedence mismatch. Think about what it takes to do something interesting with a collection of objects in c++/java/whatever, such as pick out the subset that have a cost>n: it is a loop over the entire set. Ruby makes it prettier and cleaner, but you're still just looping. Unless you create a custom collection class that internally stores a hash organized by costs. But the creation of the new class is extra overhead because the nominal unit is the single object. The counterexample is just as instructive. To retrieve the newest 10 entries in a blog uses the LIMIT syntax in SQL, which is painfully nonstandard: http://troels.arvin.dk/db/rdbms/#select-limit http://troels.arvin.dk/db/rdbms/#select-limit Things that are simple in one space are hard in the other. In my own work I've resolved some of this by attempting to avoid abusing the "standard" ORM tools that are out there that allow designing queries in your language of choice (Rails for Ruby, Hibernate for Java). Instead, I attempt to figure out exactly what I need out of query: how to structure the SQL to give me back the exact set of data I care about. No subsequent looping in Ruby/Java allowed. That forces a line in the system between the DB and the application code where each is able to be use its nominal units in as native a way as possible.