Object-Relational Mapping (ORM) is pretty ubiquitous these days. Many people take for granted that you’ll be using an ORM in your app. The question is usually “Which ORM should we use?” not “Should we use an ORM?”

This mindset leads to many misuses and abuses of ORMs. Today I’ll talk about one of them.

Imagine you’re selling widgets in a web store. You store the widget data in a table in your relational database.

When it comes time to display the widgets to your web site vistor, you use your favorite ORM to query the relational table, then row-by-row map each query result into an object. Remember, that’s the core of what an an ORM does: it maps relations to objects, and vice versa.

In the next step, you loop through your list of resulting objects, and one by one, convert them into relational data, to be displayed in a grid or table.

Wait… what?

That’s right. You used your fancy, general-purpose ORM library to automagically convert the relational data in your database, into an object. Then you wrote a manual, one-off ORM to map that object data back into relational data.

What a waste, right?

The only thing the ORM did was get in your way. And you probably didn’t even notice. You may have even said “thank you”!

Without an ORM in there, the translation from relational database rows to relational grid data is much simpler, faster, and less error/bug-prone. In fact, it may be as simple as appropriately naming the resulting columns in your SQL query (i.e. SELECT price_usd AS price).