What ORMs have taught me: just learn SQL (2014)

Join the discussion

• Hacker News
• > August 3, 2014

  That's important. Because now days it's trivial for LLMs to translate ORM to SQL and vice-versa with ~100% accuracy. I haven't written any raw SQL (only Active Record) in about two years, and the odd time I blunder with AR and create an n+1 I find out about it via error tracking (e.g. Sentry) a few minutes later and fix it. No biggie.

  There's also an additional layer of protection in that using AI on the codebase can spot SQL blunders incidentally (i.e. you ask about X, and the AI does X but also says "Not asked, but flagging for your attention: problem with SQL on line 256 etc.."

  by nomilk
• ORMs taught me that relational databases are an operational anti-pattern.

  NoSQL for operational data storage is more efficient and cost effective.

  ORMs were a regression test that exposed unnecessary complexity.

  by ChicagoDave
• I’ve never seen any reliable service built on a NoSQL store as a primary data store. If data consistency and not losing customer data important for you, RDBMS are just fine.
  by zsoltkacsandi
• LLMs are better at writing raw queries now and knowing the consequences of how it fits in your architecture (if you ask)

  So I think the ORM debate could be over

  postgresql is a beast

  by yieldcrv
• Even before LLMs ORMs are good enough to cover most of the use cases. Only some complicated use cases needs raw SQL. So you can use both.
  by senfiaj
• Next step is go down one more level to ditch SQL and learn LMDB and/or RocksDB.
  by ai_slop_hater
• ORMs make it hard to write code that allows SQL injection.
  by Dwedit
• I use both. Gorm being my favorurite
  by biglost
• ORMs are a horrible fit for OLAP scenarios. I've got a situation where I need to load ~40 tables with a total of 100k+ rows and I need it to happen at user-interactive speeds (less than 10 seconds).

  There is nothing that an ORM can do to help with this sort of problem without reaching for the obvious escape hatch of arbitrary command text execution. The ability to map the tables to objects in my programming environment is a distracting clown show for this specific problem. What really matters is understanding the provider and its techniques for bulk loading records. No ORM will ever be able to touch these provider capabilities on their "happy" paths. At best you'll wind up using the ORM and a bunch of provider-specific SQL anyways.

  ORMs for schema management is a stronger argument, but only in cases where the codebase/service has complete ownership over each respective database. Any kind of heterogenous workload says that ORM for schema management is a potential nightmare unless you do something like create a project that is only for migrating the schema, at which point I'd argue you could just maintain a source controlled folder of sql/shell scripts.

  by bob1029
• ORM is a great tool for data input. Complex output I always write the old and good raw SQL query.
  by r2ob
• Something I'd like to see is for someone to finally come to the realisation that the right thing to do is to make the front-end web templating language truly polyglot and support SQL natively, without an ORM wrapper.

  For example, the ASP.NET Razor syntax allows HTML and C# code to be interspersed surprisingly freely:

      <ul>
      @foreach (var user in Model.Users)
      {
        <li>@user.Name</li>
      }
      </ul>
  

  Just picture the same kind of thing, but with SQL expressions freely interspersed with the programming language.

  Just like how Cargo, NuGet, NPM, etc... can import packages and/or how you can cross-reference projects in build systems, web apps should be able to reference a database schema project directly, importing the SQL definitions without any explicit "mapping". If the SQL changes, the type changes, and the build system picks that up automatically without any additional manual steps.

  .NET with EF Core is almost there, and I've seen some half-hearted attempts in various languages over the years, but it's like the industry has an allergy to the concept.

  Ur/Web is probably the closest to the idealised concept, and I think that's what I read years ago that put the dream in my mind: https://dl.acm.org/cms/attachment/feb131ab-37e1-4638-be17-ab...

  by jiggawatts
• What ORMs have taught me: just do not learn SQL. I don’t for 21 years of coding.
  by ianberdin
• > Most of that has been with SQLAlchemy (which I quite like) and Hibernate (which I don’t)

  Can the OP expand on why this is? Just curious.

  by armdave
• Back in the day I made few ORMs for myself exactly because I knew SQL. It's not great.
  by scotty79
• Does my opinion on SQL and ORMs matter anymore? What does Claude think about ORMs an SQL? So far Claude seems to be content with my existing patterns of using JPA/Hibernate. We've been having this conversation since the early 2000s. Will we have it next year? Maybe just for fun... to pretend we are still relevant :(
  by teliskr
• I don't like the title, it implies that the only reason for using an ORM is not knowing SQL, which is obviously not the case.

  Every time I tried to do a project without an ORM, using only raw SQL, I inevitably ran into:

  - serialization/deserialization boilerplate. Like, having to manually map values returned by the DB library to object (or named tuple, or structure) properties

  - poor code reuse, having multiple very similar queries that have just one small difference

  - extra pain in changing DB schema. Adding a field requires to go and manually edit many queries

  Anti-ORM crowd never gives a good answer to these issues.

  Instead, they push strawman attacks like "oh, you only use ORM, because you can't write raw SQL". I can absolutely assure you that this is not the case. Every time I use an ORM (SQLAlchemy mostly, the one mentioned in the article) I am 100% sure what SQL do I want it to produce and what SQL will a particular ORM invocation produce.

  by vova_hn2
• Ecto in Elixir has a decent balance and is nice to use though Elixir doesn't have objects, but the abstraction layer is handy.
  by taatparya
• ORMs may be convenient, but only as long as you stay within their limitations. One you surpass those, things get much more complicated and messy. SQL does not have that artificial breaking point.
  by classified
• Oh no, this meme again. Of course you should learn SQL. But also, you can use a library to help generate SQL based on classes and objects that you change, so you don't have to repeat yourself. Why don't you use both?
  by Demiurge
• I never use ORMs. But slightly before 2014, there was still kind of a reason to use them, getting/setting a whole nested bag of fields at once that you don't care about individually. Json/jsonb now handles that better.
  by zadikian
• Mybatis was a thing even back then... you still need a domain model after all
  by avereveard
• I've been using ORMs since the late-90s with WebObjects (I still have a running product on the internet that uses WebObjects). I've used I don't even know how many other orms. But it's always been a mix of orm and raw sql, so yes learn sql. Especially useful for reporting.
  by comrade1234
• I thought this was well put. https://web.archive.org/web/20160301022121/http://www.revisi...

  A now defunct site discussing why ORM is a poor map.

  by capitainenemo
• I thought ORMs are trying to solve the problem of type mapping between SQL and your backend language.

  Admittedly, this doesn't end up being great, but it seems hard to solve this well in other ways, as much as I wish I could write SQL and get types for free.

  by ixxie
• I am no SQL God by any means, but I am quite proficient. Despite my SQL skills, I cannot give up EF Core.

  Even when using other languages, I just pine for LINQ/EF Core. It's truly the best ORM in my opinion. Also, even if one does not want to use the LINQ or the Query syntax (I forgot what it was called), the ability to execute SQL is also still a game changer.

  by hirvi74
• As someone who has historically spent a lot of my time with C#, and now spend most of my days writing python… LINQ is typically what I miss most from C#… (obviously aside from static types and compiled binaries).
  by sota_pop
• I feel like ActiveRecord has none of these problems, but I also feel some strong confirmation bias.

  Can anyone that has used ActiveRecord share their opinion?

  by Kaliboy
• ActiveRecord does have the problem of excess joins though.
  by dzonga
• Also, NoSQL taught me to love SQL.
  by danlugo92
• Especially Dynamo DB.
  by pjmlp