Here's a question. WHY do we even bother with ORMs? Put another way, what problem are they trying to solve?
What ORMs have taught me: just learn SQL
61–70 of 245 posts
Re: What ORMs have taught me: just learn SQL
#62A small nit on the opening:
> ... ORMs are more detriment than benefit. In short, they can be used to nicely augment working with SQL in a program ...
That statements contradictory.
Re: What ORMs have taught me: just learn SQL
#63I used to write raw SQL for many years, then, around 2005 switched over to ORMs in order to be able to target different databases, have a nice model, etc. Lets be honest here, the ease of justing doing: p.username = "Carl" p.age = 33 p.save instead of "update users set username=:username, age=:age where id=:id" has a ton of advantages. For one, some sort of syntax or type checker is actually trying to understand your…
Thanks for sharing your experience. I've been meaning to try Slick, and YeSQL sounds like a nice way to reduce some boilerplate with no real downside. I go back and forth about how I feel about ORMs. I think everyone can agree you'll need to learn SQL for any non-trivial project, even if you end up using some abstraction on top of it. On a tangent: you mentioned Upserts in Postgres features. I thought Postgres didn't…
Postgres still doesn't. I usually write a rule to do so. For instance, here's my "ON DUPLICATE KEY UPDATE eid=eid":
CREATE RULE location_updates_on_duplicate_ignore AS
ON INSERT TO location_updates
WHERE (EXISTS (SELECT 1 FROM location_updates WHERE (eid = NEW.eid)))
DO INSTEAD NOTHING;
Re: What ORMs have taught me: just learn SQL
#64I agree that SQL is a brilliant data processing language, while C#, Java or C++ are terrible at it. And there are obvious benefits to learning SQL and being able to use it efficiently, makes imho much more sense than throwing away RDBMS because they're 'slow'. But if you write applications in an oo language objects are quite natural way of representing both data and logic. Sometimes you do application-level transacti…
I believe that C# is a better data processing language than SQL is, assuming it can access the data. That's mostly thanks to the strength of linq.
Re: What ORMs have taught me: just learn SQL
#65In Django, for me the killer feature of the ORM is that it's (mostly) database agnostic, which means that you can use Postgres in production and in-memory sqlite when testing, which makes testing a gajillion times faster. If you start writing custom SQL you have to introduce horrible bodges to work with whatever database is in use.
That makes testing faster, sure, but then when you deploy your app to production you can get lots of weird errors because SQLite is weakly typed and Postgres is strongly typed, for example. Using the same DBMS in dev and prod is a best practice for this reason, even if it makes your test suite run slower.
Re: What ORMs have taught me: just learn SQL
#66I think the problem is when ORM influences/encourages particular schema designs. When you no longer see tables as tables (which is storage) and rather see your database tables as instances of objects (how you would like to consume the data)
ORM (rails/AR in particular) makes it very diffcult to work with joins and build an object that read from multiple tables.
One workaround I think is to use database views. And see views as "instances of objects" and back ORM classes with them.
Re: What ORMs have taught me: just learn SQL
#67Earlier quoted context omitted.
(caveat: I'm a developer but I haven't used ORMs very much.) Don't most ORMs let you write raw SQL when you really want to? In that case, you could use the ORM for simple things, but revert to raw SQL when you need more power. Or is that not the case?
Yes, but the ORM often influences the schema design. That can be very painful down the road when you realize your tables are actually tables, rather than instances of objects, which would be what your ORM led you to believe.
I think the problem is not that an ORM often influences schema design, it's that Relational Databases/SQL often influence application design.
People complain that an ORM isn't using a relational database effectively. The greatest contribution of the rise of ORMs is that relational databases are hard to use properly.
Bring on the ACID compliant document databases.
Re: What ORMs have taught me: just learn SQL
#68I have a laravel project for which all of my models are raw SQL statements for this reason. At the very least, it makes the code more portable, and it makes it easier to reason about the statements when you can actually see them.
It makes your code less portable. Raw SQL means you're essentially tied to a single DB provider. What happens when you need to move to a different one?
What if you don't need to move to a different one?
Re: What ORMs have taught me: just learn SQL
#69I have a laravel project for which all of my models are raw SQL statements for this reason. At the very least, it makes the code more portable, and it makes it easier to reason about the statements when you can actually see them.
It makes your code less portable. Raw SQL means you're essentially tied to a single DB provider. What happens when you need to move to a different one?
Then you should probably rewrite your statements anyways to take advantage of platform-specific features. I won't write a query on MySQL the same as I would on Postgres, because there's usually a better way.
CRUD is about all that can honestly stay the same, as IMO that's where ORMs shine.
Re: What ORMs have taught me: just learn SQL
#70> A recent count of one such table in my work resulted in over 600 attributes and 14 joins to access a single object, using the preferred query methodology At some point between inception and having 600 columns someone had to have stepped in said is this necessary? Maybe I haven't worked with big enough data sets, but to me that number seems insanely high - and I really don't see how the ORM would be any worse than r…
"It sounds to me like best practices SQL are being compared with worst practices ORM."
AMEN.
I've written bad SQL and good SQL. I've written bad ORM stuff, and good ORM stuff. You don't learn how anything is bad until you make mistakes and learn from them. Ideally you learn from others' mistakes too, but some things you just end up having to internalize through experience.
I still take a decent ORM over raw SQL for 90% of the work I do, because much of it is boilerplate/repetitive stuff. Knowing something else will handle escaping and basic relations for me without a whole lot of boilerplate behind it is great, then I write some SQL by hand when I hit a wall with the ORM (complexity or performance). If you're trying to fit 100% of every single data query in to an ORM, and you bend the data too much to fit the constraints of the ORM tool, yes, there will be problems. But that's sort of just common sense - once you feel you're forcing a tool to do something it's not suited for, back up and ask if there's a different way to get your results; doesn't have to mean throwing out the whole tool.
I've worked with plenty enough stupid "raw SQL only" projects to know the real answer to all this is experience and knowledge, vs just following 'one true path' regardless of your ability to understand it. Ever had a user table with 190 columns, named "is_usa", "is_argentina", "is_germany", etc, one for each country, so the developer could determine what country someone lived in? Every single request, 190+ queries: "select is_argentina from user where id=5", "select is_iran from user where id=5", etc. But hey, it was done by hand - no evil ORM to hinder the awesomeness of raw SQL, right?