4 ms·

Every project I've seen that refused to use an ORM in favor of their own home grown solution was worse off for doing so. Almost every time someone claims that t

by pg_bot 7y ago

Every project I've seen that refused to use an ORM in favor of their own home grown solution was worse off for doing so. Almost every time someone claims that the ORM can't be used, I would point out how it could and that code became simpler and easier to maintain. If they read the documentation and used a bit of creativity instead of fighting against their tools, they wouldn't be left with such a mess. This post reads to me as the author not having the proper ability to structure and plan their projects so they blame their tools instead of themselves. So instead of understanding limitations and tradeoffs, they try to build their own magic lamp that solves every problem under the sun.

reificator 7y ago
I've had to put up several services throughout the years that performed exactly one or two queries, and a few more that performed less than five. It was a matter of setting up the database, writing a prepared statement, and calling that prepared statement with the relevant arguments. Bringing in an ORM for these cases is absolutely overkill. As your requirements constantly balloon, perhaps adding an ORM (or just a simple query builder) is appropriate. But none of the services I mentioned above have grown in that manner, and most are still up and have been running (and modified) for several years now. I've been on projects where an ORM and/or query builder was likely the right answer, especially for automated migration and rollback scripts. But the way you're presenting it seems to be all or nothing, and I couldn't disagree more.
aforwardslash 7y ago
My experience is actually the opposite - every project I worked on that relied on an ORM actually benefited from replacing it with a clear architecture pattern and a query builder. Having the concrete notion of what is being passed to the DB allows easier debugging, and it is way easier to solve performance bottlenecks. As an example, recently I replaced several hundred lines of complex ORM oriented code with a 10 line CTE that would perform the iteration and calculation being done on the client side - the result was a 10x increase in performance with a fraction of the memory. By not using an ORM, the developer also stops treating the database as a "black box". It is a "black box" conceptually, but the more you understand how it works, the better your applications will perform. As an example - knowing if, inside a transaction, when you're performing a read it comes from the server you just started the transaction or some slave that may or may not be updated (due to propagation delay) may seem picky, but its one of those things that is very hard to debug afterwards as a transient error.
- pg_bot 7y ago
  My ORM (and probably yours) handles CTEs ;)
  - aforwardslash 7y ago
    Yes and no, it seems its an external module. And this is part of the problem - why would I need an external dsl extension to translate a pure relational concept into SQL? Debugging the query will require sql knowledge, regardless of ORM.In fact, the ORM is another layer to be debugged, it just adds complexity.

by pg_bot 7y ago

reificator 7y ago

I've had to put up several services throughout the years that performed exactly one or two queries, and a few more that performed less than five. It was a matter of setting up the database, writing a prepared statement, and calling that prepared statement with the relevant arguments. Bringing in an ORM for these cases is absolutely overkill. As your requirements constantly balloon, perhaps adding an ORM (or just a simple query builder) is appropriate. But none of the services I mentioned above have grown in that manner, and most are still up and have been running (and modified) for several years now. I've been on projects where an ORM and/or query builder was likely the right answer, especially for automated migration and rollback scripts. But the way you're presenting it seems to be all or nothing, and I couldn't disagree more.

aforwardslash 7y ago

My experience is actually the opposite - every project I worked on that relied on an ORM actually benefited from replacing it with a clear architecture pattern and a query builder. Having the concrete notion of what is being passed to the DB allows easier debugging, and it is way easier to solve performance bottlenecks. As an example, recently I replaced several hundred lines of complex ORM oriented code with a 10 line CTE that would perform the iteration and calculation being done on the client side - the result was a 10x increase in performance with a fraction of the memory. By not using an ORM, the developer also stops treating the database as a "black box". It is a "black box" conceptually, but the more you understand how it works, the better your applications will perform. As an example - knowing if, inside a transaction, when you're performing a read it comes from the server you just started the transaction or some slave that may or may not be updated (due to propagation delay) may seem picky, but its one of those things that is very hard to debug afterwards as a transient error.

pg_bot 7y ago
My ORM (and probably yours) handles CTEs ;)
- aforwardslash 7y ago
  Yes and no, it seems its an external module. And this is part of the problem - why would I need an external dsl extension to translate a pure relational concept into SQL? Debugging the query will require sql knowledge, regardless of ORM.In fact, the ORM is another layer to be debugged, it just adds complexity.