3 ms·
Laurie, this is a good restatement of the age-old problem of Object/Relational impedance, the perennial bugaboo of many an architect, developer, and DBA. It's t
by davesims 15y ago
Laurie, this is a good restatement of the age-old problem of Object/Relational impedance, the perennial bugaboo of many an architect, developer, and DBA. It's true that ORMs are merely bandaids on what is essentially an intractable set-theoretical problem, but we've learned over the years that in the right hands an ORM is a tremendous productivity boost, provided the team is aware of the limitations. In fact Martin Fowler's original definition of the ActiveRecord pattern in Patterns of Enterprise Application Architecture describes some of these limitations from the very beginning.
"Unfortunately, these advantages disappear as the project increases in complexity: the abstraction breaks down, forcing the dev to use and understand SQL"
"Forced" to use and understand SQL? I think you have a basic misunderstanding of the purpose of ORMs, Laurie. The developer who can't use and understand SQL really has no business going near the ORM. They probably need to stay somewhere near the front-end doing design, layout and UI-centric work.
The purpose of an ORM, properly used, is not at all to completely remove SQL from the developer's toolkit, but to help developers who fully understand SQL and Objects eliminate boilerplate SQL. This has a huge dual benefit of productivity boost plus elimination of bugs by the reduction of code/SQL duplication.
If an ORM developer is not aware of SQL (i.e., watching their rails log for odd queries/joins) and the natural problems that arise, such as n+1, etc. then they probably shouldn't be writing data-layer concerns. ORMs are for experienced developers who know how to use things like the ActiveRecord or DataMapper DSLs when appropriate, and can also drop into straight SQL when appropriate. ORMs are power tools for serious developers who can use them for what they do well, and know how to avoid their weaknesses, which you outline well here.
Because of their benefit and the cumulative experience we've had in the last 10 years or so getting to know how to use ORMs effectively, they're not going away any time soon. However, they certainly have their pitfalls and it's important that we have posts like these every few years or so to remind us what those pitfalls are. So thanks!
- j-kidd 15y ago> The developer who can't use and understand SQL really has no business going near the ORM. Absolutely. First we have developers trying to use ORM (a.k.a. HideSQL) to avoid learning SQL. That fails. Now we have developers trying to use NoSQL to avoid learning SQL. This "avoid learning SQL" thing is shaping up to be a fantastic anti-pattern. I wonder what's next.