Reginald Braithwaite blogs that Relational Calculus is about Relations, not Rows, quoting from this entry at Enfranchised Mind:
To faithfully model SQL we must, on some level, faithfully model the relational calculus. And this is where I think the Object Oriented programmers go astray in trying to interface to SQL. In their hurry to make things into objects, they immediately (and without fail) declare the rows to be objects–and thus miss the fact that relational calculus and thus SQL is about relations, not rows.
I’ve often said that complex problems are just simple problems which are not well defined or correctly articulated. OO-heads rage against the ORM problem because they’re not solving the ORM problem, they’re solving something else. To solve the ORM problem, you have to understand that the basis of the problem is in adequately representing the fundamental operators of relational calculus–join, selection, projection–then combining them in ways that produce higher-order behaviors which implement the functionality required.
Simply serializing objects into a matrix representation is not “solving the ORM problem.” This is my biggest criticism of the ActiveRecord in Ruby on Rails: if your problem is so simple that pregenerated scaffolds and ActiveRecord is adequate, then your problem is so trivial it’s non-interesting. The challenge is for an OO language to facilitate representing the relations between objects, the semantic information about how one object’s data values can be derived using the three relational calculus operators from other data. At that point, why not simply learn and use SQL directly, rather than extending your favorite language with what is essentially a dialect of SQL?
Of course, when the majority of software developers are just tool users and not artisans who actually create things, it’s really a moot point. “Web 2.0” has brought us a lot of new applications, but they’re all fundamentally the same. Ruby on Rails and ActiveRecord offers a solution to the CRUD problem to the tool users, but that hasn’t been interesting for years now. What’s needed now is a way to provide the mass of tool users to create novel permutations of the tools they have, not just continue to replicate slightly varied instances of them.
Tags:
Reginald Braithwaite,
programming,
relational calculus,
object-relational mapping,
Ruby on Rails,
ActiveRecord
Programmer, husband, father, singer, guitarist, tinkerer, reverse engineer, strange, and living in New Jersey. 
if your problem is so simple that pregenerated scaffolds and ActiveRecord is adequate, then your problem is so trivial it’s non-interesting
That’s exactly the point of ActiveRecord: the needs that most web apps have for databases is simple and uninteresting. AR lets the coder spend as little time on the problem as possible.
(Also, openid login is broken on your blog.)
Well stated. Rows aren’t objects and vice versa!
This is why Microsoft’s LINQ is a winner when so many ORM’s are losers that sound good in practice but don’t cut the mustard when you try them in enterprise apps.
Chase: what would you say are the distinguishing features and/or reasons Microsoft’s LINQ is better? At a glance, it looks like just another set manipulation API.