No
Boggles the mind
What ORMs have taught me: just learn SQL (2014)
51–60 of 360 posts
Re: What ORMs have taught me: just learn SQL (2014)
#52This topic has been done to death and the rate at which comments have been made since this was posted tells me that we either haven’t learned much of anything as a collective, or we just like to rehash the same talking points because... we can.
Know how and when to use ORMs. Probably learn SQL first. Don’t believe that any shiny bullet is silver.
Or in short: “No”
Re: What ORMs have taught me: just learn SQL (2014)
#53Why are we even having this debate? There are some ORMs that bring so much value to the table that you'd be stupid not to use them. Example being Django's ORM or SqlAlchemy. Also be specific in what ORM you are comparing to raw SQL. Are you talking about Hibernate or SQLAlchemy. Are you talking about a query builder? Good ORMs help tremendously with maintainability and security. They also let you drop down to raw SQL…
I've used SQLalchemy a lot. I've even written a keyset paging extension for SQLalchemy. But recently I've switched to writing stored procedures and calling them directly, instead of going through an ORM for everything... And it's so much easier.
One problem with having logic in the DB is that it's much harder to scale if you need 10x more computing power.
Re: What ORMs have taught me: just learn SQL (2014)
#54An ORM is not a "query builder" An ORM turns your result into a collection of objects. THAT is what an ORM is for and about. The fact that they are built on top of query builders and lighten the load when developing is just a handy side effect.
To me, it hinges on what you mean by "a collection of objects." If it is just a list C-like structs, that's great. If it involves lazy-loaded child collections, inheritance hierarchies, or any kind of behavior at all, that makes me worried.
Re: What ORMs have taught me: just learn SQL (2014)
#55The first time I've seen an ORM I was fascinated by this seemingly beautiful idea. But I have quickly realized that it's almost useless in real life projects, plain old SQL seems just much much better. Now I don't understand why would anybody use an ORM actually.
Also, basic SQL can be easily taught in as little as 10 minutes (I have been initially taught it at middle school during MS Office Query, Access and VBA class). An image of a programmer that can't use SQL (I don't mean advanced cases which can indeed be a bit tricky but these are far beyond the powers of any ORMs anyway) seems really bizarre to me.
Re: What ORMs have taught me: just learn SQL (2014)
#56> If you're using an RDBMS, bite the bullet and learn SQL. If this person spent all that time using Hibernate and then SQLAlchemy, and all that time did not know SQL, then their suffering and bad experiences make complete sense. You absolutely need to know SQL if you're going to use an ORM effectively. Good ORMs are there to automate the repetitive tasks of composing largely boilerplate DML statements, facilitating q…
This is especially true where the ORM can mask things such as moving a column to an associated table. The ORM knows that object.attribute is now represented in the object_attribute table with the relationship using object_attribute.pk in the object.attribute column (which may or may not be renamed to attribute_id).
No need to rewrite all your SQL, just the ORM description of the model!
Re: What ORMs have taught me: just learn SQL (2014)
#57The post is from 2014, so I won't be too harsh here. The author's problem is with some specific flavors of ORM he's used, and shouldn't be generalized. Hibernate's expressiveness is/was crippled by Java itself. C# ORMs on the other hand are way better because they benefit from LINQ which adds queries natively into the language. Other more expressive languages have excellent ORMs as well.
The objective of ORMs is not to replace 100% of your queries. That 10% might still require SQL or Stored Procs and that's fine.
ORMs give you:
1. Type safe queries
2. Ability to refactor easily, click to rename prop
3. Not having to handcode joins if objects are related
customers.select(c => { cust: c, orders: c.orders })
//If getOrders() returned a query expression
getOrders().where(o => o.city === "London")
//You extend it further
getLondonOrders().where(o => o.total > 200)
//^ These queries aren't executed yet.Re: What ORMs have taught me: just learn SQL (2014)
#58Earlier quoted context omitted.
I've used SQLalchemy a lot. I've even written a keyset paging extension for SQLalchemy. But recently I've switched to writing stored procedures and calling them directly, instead of going through an ORM for everything... And it's so much easier.
Keeping logic in the database like that means you can’t version those procedures alongside the rest of your code. That’s a pretty big downside.
Of course you can, at least I do.
In the databases I've worked with extensively (PostgreSQL and, somewhat in the past, Oracle) Store Procedures are routinely versioned controlled as part of the application, just these bits of code are in a different language than the rest.
The creation of functions/procedures is not tied to state of the database in quite the same way as tables are; the functions/procedures, where they care about the data, do need to recognize the table structure and changes to that structure, but that's no different than any other of the application code which makes use of the data in the database.
I think where many people get caught up on this is that they do something like migrations to get code, including procedural code, into the database... but that's not the only game in town. And really, given what's possible with databases today, I'm not sure migrations are even the best way anymore.
Consider a tool like: http://sqitch.org/ which facilitates not treating stored procedures as migrations, but rather as individual files which change just like any other code.
There are ways to accomplish having good version control on the table/structure side as well, which again, is something you lose with the migration tools I've worked with.
Anyway, I just don't buy this argument.
Re: What ORMs have taught me: just learn SQL (2014)
#59> If you're using an RDBMS, bite the bullet and learn SQL. If this person spent all that time using Hibernate and then SQLAlchemy, and all that time did not know SQL, then their suffering and bad experiences make complete sense. You absolutely need to know SQL if you're going to use an ORM effectively. Good ORMs are there to automate the repetitive tasks of composing largely boilerplate DML statements, facilitating q…
Everything that isn't SQL tuned to your environment forces you to sacrifice performance at some point. At some point it does an inefficient join. How can you not go back and fix performance issues is you don't know SQL? (It isn't like you need to fix it in C)
Re: What ORMs have taught me: just learn SQL (2014)
#60The post is from 2014, so I won't be too harsh here. The author's problem is with some specific flavors of ORM he's used, and shouldn't be generalized. Hibernate's expressiveness is/was crippled by Java itself. C# ORMs on the other hand are way better because they benefit from LINQ which adds queries natively into the language. Other more expressive languages have excellent ORMs as well. The objective of ORMs is not…
I've been writing C# professionally for ~5 years at this point. While I was initially quite infatuated with LINQ2SQL and EF, I have gone through the same situation as this fellow. I just write SQL in-line using Dapper for parameterization/data mapping, and use stored procs when I need some of the more arcane features of SQL (merges, CTE, etc).