5 ms·
ORMs are a tool that can be abused, but eventually you need something that loads data from your database and places it into an in-memory object. Given how repet
by mjr00 3y ago
ORMs are a tool that can be abused, but eventually you need something that loads data from your database and places it into an in-memory object. Given how repetitive the SQL and mapping code is, why wouldn't you use a tool to automate that, even if you're an SQL expert?
- nkozyra 3y agoI think there are a lot of database libraries across a lot of languages that let you jam data directly into an object. The only thing I think (some) ORMs do really well is migration management. But you can also devise your own patterns for this easily enough that it's not worth it.
- hasbot 3y agoThe SQL and mapping code is very simple. Getting an ORM to generate queries as efficient as hand written SQL requires substantial ORM study, experimentation, and ongoing tweaks. I've seen too many junior programmers write simplistic code that creates a massive number of database queries because they didn't understand how the ORM works. That rarely happens with handcoded SQL because how the code interacts with the database is transparent.
- biorach 3y agoBut in most applications only a small subset of queries need to be efficient.
- hasbot 3y agoI completely disagree but of course we probably have not worked on the same sorts of applications so we have no common ground.
- Nextgrid 3y agoYou can use both though. Keep the ORM for the easy stuff to save yourself the boilerplate, and drop down to raw SQL when needed or when it's easier than figuring out how to do the same with the ORM.
- hasbot 3y agoBut then you're still having to fully understand the ORM so you're not saving yourself any work. I'm always amazed at how much I can do in a single SQL query and how much extra code is required to accomplish the same when using an ORM. But then I once wrote a SQL compiler and runtime system so I'm quite adept at SQL.
- starttoaster 3y agoSpecifically in Golang, an issue I encountered writing SQL queries is when you expect the response will contain null fields. Specifically in Go, at least with the stdlib database/sql client, there's a lot of boilerplate code you need to add to make raw queries without an ORM to map to a sql.NullT object (where T is the Golang equivalent type for the column), then check for each row if the sql.NullT object is "valid" and then copy the column values for each row over to a new struct after doing each sequential null check. An ORM might have saved me about 50 lines of code for just this one query that I'm looking at, just in handling null types alone.