What ORMs have taught me: just learn SQL (2014)
1–10 of 654 posts
Re: What ORMs have taught me: just learn SQL (2014)
#2No thanks, ORMs work fine.
Re: What ORMs have taught me: just learn SQL (2014)
#3Wholeheartedly agree. It's amazing how much work you can save by just having the database do it via a SQL query/view.
Re: What ORMs have taught me: just learn SQL (2014)
#4I’ve come to the same conclusion even working with ActiveRecord. SQL is very literally a domain-specific language for working with relational data; why would we go so far out of our way to eschew writing code in it?
Re: What ORMs have taught me: just learn SQL (2014)
#5SQL just isn't composable. I know this article is old, but these days it's not black and white. In the space between ORM and raw SQL there are things like AREL which can save a ton of dev effort without the "impedance mismatch".
Re: What ORMs have taught me: just learn SQL (2014)
#6Even if you use an ORM you should probably know SQL so you can use them efficiently. Also, if you use an ORM, make sure it "starts with database schema" not with objects. Otherwise the mismatch will probably be horrible for you. A dozen years ago I published this article on generating your domain objects from the database, still a reasonable thing to do if you want the added query expressiveness the ORMs have over most SQL generators.
https://javarants.com/generate-jpa-or-gorm-classes-from-your...
Re: What ORMs have taught me: just learn SQL (2014)
#7Wholeheartedly agree. It's amazing how much work you can save by just having the database do it via a SQL query/view.
We used to show the new developers on the team a query generated by Entity Framework...23 pages long. We replaced it with a well formatted query that fit on half a page. When I switched the team to Java + JPA, we started writing our own queries if wasn't a simple CRUD and it has been wonderful for the entire team.
I think it's easier to learn SQL than learn an abstraction of a DSL.
Re: What ORMs have taught me: just learn SQL (2014)
#8When I started web work ~9 years ago, it was with Rails and ActiveRecord, which turns out to be incredibly good for basic queries and pretty basic apps. So good to the point where I never bothered to go too far into SQL until years later, which was a mistake.
When doing work in python, I don't feel it has a comparable ORM, to where I kind of write my own files that have things like finders and updaters and creators. In most cases, I've found it's much better than SQLAlchemy. Dealing with joins, and things like math, meaning averages, sums, distributions, division, is so much better to be done in the query rather than more basic queries and looping through the results.
There are of course cases like injections to look at, but lots of things I have are calculations of data and showing it, so we're able to handle it with raw queries. Also, ActiveRecord has ways to enforce no injections.
In lots of cases, we've found that using an ORM to start, finding slowness, and moving towards raw queries is a great way to go.
Re: What ORMs have taught me: just learn SQL (2014)
#9I use a data mapping ORM and I've literally not have any of these concerns. They are all non-issues.
The first item about querying is relevant but all ORMs allow you to drop into SQL to execute a complex reporting-style query. It's not really necessary if you are just querying in objects to manipulate (which is what ORMs are good for).
Re: What ORMs have taught me: just learn SQL (2014)
#10Code thinks in objects and functions and values and pointers.
Databases think in tables and columns and rows and queries and indexes.
If you don't pick an ORM to help manage this translation layer, then you'll end up re-implementing your own. Maybe this is OK, because yours will be simpler for quite some time.
What else are you going to do? Stored procedures? Concatenated strings?