Keith Devens .com

why not?

Mainly because of leaky abstractions. As Tim Bray has said:

Lots of architects have learned, painfully, that you usually can’t magick relational rows away behind object/class abstractions. The right way to think about a database is as a set of normalized tables that are designed to be addressed with SQL strings.

Object mappings just don't map well onto relational tables. Objects have no concept of a join, for instance. On the surface, O/R mappings look extremely attractive, as they make for very elegant code examples. However, I get the feeling they're only appropriate for simple database schemas. Once you move beyond that, I can't imagine you won't hit a wall where the O/R mapping can't automatically do what you want anymore and you're going to have to speak to the database without an intermediary.

However, I (and Tim Bray, and Simon) could be wrong, and O/R mappings may work in every case and save people lots of time. But on the whole I've stayed far, far away from them, since OO and relational databases are so very different from each other. I've never bought into the idea that O/R mappings can sufficiently hide those differences and use the database efficiently.

I think it's partly just a matter of using the right tool for the right job. There are some things I do in SQL in my current project that only really make sense in SQL, so for that project, I need to have access to a real database connection. On the other hand, when I was hacking out a bug tracking system a few months back, I was basically just using the database as object storage, and didn't need to do anything more than a few simple selects and joins. I used SQLObject, and found that it did everything I needed. I could have done without it, but it would have been considerably more coding in both SQL and Python.

Of course, part of the reason I was comfortable using SQLObject is that it's fairly transparent--I can usually tell what it's doing in SQL, and it won't break if I talk to the database directly. I wonder if that can work as a general rule. It's okay to use an abstraction if you can get behind it when necessary?

Keith, object graphs and relational tables are actually almost isomorphic - foreign keys are nothing but pointers! If you want to try a truly fantastic O/R mapper, give the <a href="http://www.helma.org">Helma Object Publisher</a> a shot. I usually handle scenarios one would usually use queries for with a bunch of collections (usersByLastName, usersByAge, User.storiesByModificationDate &c.). It works great.

I have worked with Hibernate (probably the best open-source O/R mapper for Java) in a Swing context, and there it's been a mixed blessing - but for web applications the problems we encountered in a desktop application environment are usually eliminated by the rigid request/response cycle (whereas with a desktop application, the object graph can be in different states in different windows, which makes the question when to actually commit stuff &c. a tricky one).