The concept of ORM isn't necessarily bad, it's just that most ORMs are terrible and try to map too much of relational algebra to objects, even if it is a bad fit.
Good ORMs like SQLAlchemy first model a relational database and then build the object bits on top of that. That's why you can do an explicit outer join between models so you end up making a constant number of queries (instead of n queries with the naive attribute fetch in a loop).
One almost never has to write SQL when using SQLAlchemy, as opposed to, for example, Django's ORM, which has a much more "mainstream" design. SQLAlchemy is more like a relational/SQL library + an optional ORM-like thing.
I've worked with ORMs that make it difficult to write specific kinds of queries, and that's usually because the ORM is designed to be robust enough. However, even that ORM would allow you manually write a query and then run it and it would convert the results back into lovely packaged objects to pass around and work on.
In a language like PHP there's a lot of annoying boilerplate you have to write around every query you run by hand like looping over the result set that an ORM can just convert into a pretty little associative array for you with a consistent structure.
As far as I'm aware, any ORM allows for hand-written queries, so if the argument is that ORM-generated queries are too bloated/slow, you can still write optimized queries where needed and still take advantage of the automatically conversion of the result set to a useful object.
The main advantage as far as I'm concerned is semantic integrity. You stil get to think and model in OOP terms.
That's valuable and good abstractions are worth some trade-offs.
Of course you also get that if you use an object database like ZODB but you face similar trade-offs most noteably speed which is usually solved by using a RDMS for indexing.
I think this guy "don't get" many things about ORM like:
- They insert a great deal of incidental complexity in your solution.
- Most DBAs are specialists in SQL and relational databases not OO or JPQL, etc.
- If you have to read a 880 pages book to really understand your ORM framework there's something wrong with it (java overengineering probably).
ORM offers robustness to a subset of relational database abilities, at the cost of simplicity. That's philosophically wrong IMHO - it's too great a loss of functionality, time and attention for replacing something I don't yet have any need to replace.
Whilst I dare say there're applications where ORM is the only sensible choice, I've yet to see any trace of them in my (fairly) varied experience.
Maybe if one tries to do as much as possible from within the database itself (i.e. implement business logic using stored procedures, triggers and such, not an external programming language), there will be no need for any ORMs whatsoever? That's a honest question btw, I don't have much experience with databases, just curious to know.
9 comments
[ 5.2 ms ] story [ 32.8 ms ] threadGood ORMs like SQLAlchemy first model a relational database and then build the object bits on top of that. That's why you can do an explicit outer join between models so you end up making a constant number of queries (instead of n queries with the naive attribute fetch in a loop).
One almost never has to write SQL when using SQLAlchemy, as opposed to, for example, Django's ORM, which has a much more "mainstream" design. SQLAlchemy is more like a relational/SQL library + an optional ORM-like thing.
In a language like PHP there's a lot of annoying boilerplate you have to write around every query you run by hand like looping over the result set that an ORM can just convert into a pretty little associative array for you with a consistent structure.
As far as I'm aware, any ORM allows for hand-written queries, so if the argument is that ORM-generated queries are too bloated/slow, you can still write optimized queries where needed and still take advantage of the automatically conversion of the result set to a useful object.
That's valuable and good abstractions are worth some trade-offs.
Of course you also get that if you use an object database like ZODB but you face similar trade-offs most noteably speed which is usually solved by using a RDMS for indexing.
Whilst I dare say there're applications where ORM is the only sensible choice, I've yet to see any trace of them in my (fairly) varied experience.