11 ms·

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

• yieldcrv 2mo ago
  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
  • senfiaj 2mo ago
    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.
• deterministic 2mo ago
  That hasn't been my experience at all. We've been using a custom code generator for years to build a large number of business-critical applications. The generator takes a single specification and produces everything needed for the server, client, and databases (SQLite, Oracle, in-memory, etc.) to stay perfectly in sync. It has worked really well for us and has been a huge productivity boost.
• nijuashi 2mo ago
  I remember showing a similar article to a teammate in a class to warn him about overcomplicating the assignment by using ORM. He said that the idea is beyond contempt and went ahead and used ORM. We didn’t finish the assignment.
• appganvwale 2mo ago
  [flagged]
• ai_slop_hater 2mo ago
  Next step is go down one more level to ditch SQL and learn LMDB and/or RocksDB.
• add-sub-mul-div 2mo ago
  2014: people respond with indignance that they should have to learn SQL now that there's a shortcut 2026: people respond with indignance that they should have to learn anything now that there's a shortcut
  • flir 2mo ago
    I like SQL. I enjoy writing SQL. I find ORMs produce crap SQL. But the current shortcut du jour is pretty damn good at writing SQL.
    • mrweasel 2mo ago
      While I do enjoy the Django ORM, for many queries SQL is just better. It's almost as if it was designed for querying database. Once you hit a certain level of complexity in your queries, you're better of with SQL. It's not that you can't do the query in the ORMs, but you're then looking at learning their special query language and those are never better nor easier to understand than just SQL. Those ORM query languages certainly aren't transferable across ORMs, but SQL frequently is. If you can query MariaDB with SQL, you can query SQLServer and PostgreSQL. The same can't be said for e.g. Django vs. Hibernate. For the "give me all the entries, with this one property" ORMs a much quicker and easier to work with. Once you start needing to use subselect, multiple joins, weird ranges or constructing object with data from across tables, I'd rather just write the SQL myself.
      • airstrike 2mo ago
        And Django makes it ridiculously easy to write those raw queries in SQL directly so it seems like you're getting lots of mileage from the ORM without giving up anything
    • 3eb7988a1663 2mo ago
      I write SQL every day, but I cannot get onboard with liking the language. Yes, it is incredible that the language has had such staying power. No, it is not great that such a flawed design has persisted. I enjoy this article[0] about some of the persistent warts which will seemingly never change. [0]https://www.geldata.com/blog/we-can-do-better-than-sql https://www.geldata.com/blog/we-can-do-better-than-sql
• valzam 2mo ago
  The big problem is that raw SQL has pretty bad type inference and linting support in most editors. A query builder can still give you a lot of type safety benefits.
  • Arch-TK 2mo ago
    A query builder is not an ORM. ORMs build queries for you, but a query builder does not need to be an ORM.
    • win311fwg 2mo ago
      ORMs do not inherently build queries. They only provide data transformations between relations (i.e. rows and columns) and objects. Hence the literal name: Object relation mapping. You can absolutely have ORM without query building just as much as you can have query building without ORM. Sometimes ORMs and query builders are combined into a higher order system, such as what is described by the active record pattern. This might be what you are actually thinking of instead?
      • Arch-TK 2mo ago
        Okay, so I have an object like: User { name friends: List<Friend> posts: List<Post> } Let's say we have a "MappedUser" which is derived from this type by this ORM. I now do: user = get_mapped_user() for post in user.friends[0].friends[0].posts { ... } Ignoring "get_mapped_user()" how does our user object work? What happens when I access `.friends`? Does it give me an empty list, because I didn't ask for it? I am not aware of anything that calls itself an ORM which merely does: user: User = map_from_relational_to_user(query_user()) Not only is it difficult to conceptualise how this operation would ever meaningfully work for any non-trivial query, it's also difficult to see how it would even work for trivial queries. ORMs, at their core, try to abstract away something like `user.friends[0].friends[0].posts` more or less into some underlying queries against a relational database. The main distinction between them being in the availability and first-class nature of the escape hatches when this operation inevitably becomes slow.
• sbuttgereit 2mo ago
  Just one quick note... > ...(although things like Postgres’ hstore can help)... Back when this blog post was written, this advice would have been reasonable. Today, I don't know anyone reaching for hstore since the more featureful json support was added.
• danlugo92 2mo ago
  Also, NoSQL taught me to love SQL.
  • pjmlp 2mo ago
    Especially Dynamo DB.
• noisy_boy 2mo ago
  As someone who started their programming journey with SQL, it just feels so odd hearing about learning SQL being presented as an useful option. I get it, it just feels odd. SQL was considered table stakes in the financial IT world - if you said you didn't know SQL, people would look at you funny.
  • bluefirebrand 2mo ago
    It's very strange too. You can learn something like ~90% of useful SQL in an afternoon. The remainder is stuff that you only really need for extremely performance sensitive operations
    • noisy_boy 2mo ago
      That is exactly what I was thinking. There is such a low barrier to entry with an outsized payoff.
    • crispyambulance 2mo ago
      > You can learn something like ~90% of useful SQL in an afternoon. Oh, HELL NO! It's an ugly little language that one has to come back to and re-learn over and over at different levels of sophistication. Nothing wrong with that, but to suggest it's trivial is a gross mischaracterization.
      • bluefirebrand 2mo ago
        > different levels of sophistication Most of those are not necessary for 90% of use cases I'm not taking the piss either All most people really need to know is table CRUD, row CRUD, and a bit about indices. For anything more advanced you'll need a DBA, but IMO you unless you are scaling like crazy you will not need much more than that for SQL knowledge. It's really, really not that complex for most use cases
        • therealdrag0 2mo ago
          You should also learn joins and ordering/pagination. But that can be on day 2 :)
• scritty-dev 2mo ago
  the N+1 trap and having to incorporate eager loading dictates you need to pretty much understand SQL regardless. applying the object oriented paradigm to relational data created Frankenstein's monster which we unaffectionately refer to as ORMs
• teliskr 2mo ago
  I use both SQL and ORMs every day. I've used hibernate since 2004. I've certainly had some difficult times with it; but overall it is a net positive. I find that it generally works well and saves a ton of time as long as I stick to my known patterns.
• stephen 2mo ago
  I'm admittedly an ORM apologist [1], but a few of his points articulated as "deal breakers" aren't that bad imo: - "the pernicious use of foreign keys [...] links between classes are [...] foreign keys" ==> that just sounds like schema normalization, which is usually a good thing? - "bending over backwards [...] to generate SQL that runs efficiently" ==> the huge majority of ORM-driven queries are "select * from table where id in ..."; for the queries that are more complicated than that, then yes use SQL! That's allowed! Folks who dislike ORMs seem to have this false dichotomy that "the ORM _must_ be used for all queries", which is a self-imposed/unpractical restriction. - "dual schema dangers" ==> he's exactly right that database should own the schema definition, but then just codegen the entities from the db schema? That's your singular source of truth, no drift. You can do this with Hibernate, ActiveRecord, Joist, many ORMs. - "Identities" ==> ironically I think ORMs (that use the unit of work pattern) actually have net-better DX here b/c you can hook up a graph of entities with just references. I.e. hook up a book to its author w/o knowing their ids yet, which explicitly avoids the annoyance he mentions of doing a partial commit/going to the db to figure out "what value should I INSERT into in the book.author_id column?" (but my author is new) in the middle of your business logic that just wants to "create books". - transactions ==> agreed that "transactions via annotations" ala JPA/Hibernate are terrible, but afaiu all "internet scale" apps these days do reads outside of transactions, and just use op-locking during the singular flush/commit step to the db. Disclaimer I am sure I won't change anyone's minds :-) Edit: in the HN comments, we're debating "the best way to generate SQL", which is fine, but imo it overlooks the biggest value for ORMs: enforcing business invariants. I.e. yes a simple INSERT is trivial is write, "why have the ORM to that!", but are you going to enforce the same business logic in the 10 places you do `INSERT authors` in your codebase? And if the answer is "I write an single `insertAuthor` abstraction to enforce this" then you're half-way to writing an adhoc half-specified, bug-riddled version of what a reactive ORM like Joist will do for you. [2] :-) [1] https://joist-orm.io/ https://joist-orm.io/ [2] https://joist-orm.io/modeling/why-entities/ https://joist-orm.io/modeling/why-entities/
  • swasheck 2mo ago
    > Folks who dislike ORMs seem to have this false dichotomy that "the ORM _must_ be used for all queries", which is a self-imposed/unpractical restriction my experience is the exact opposite. People who love and advocate the merits of ORM insist that everything be executed through ORM because it introduces too much complexity for them to blend handwritten SQL with the ORM generated queries
• bob1029 2mo ago
  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.
• gedy 2mo ago
  One nice thing about the rise of ORMs back in the day was it broke the stranglehold our traditional DBAs had on the data tier. I respected them and their skills, but in a product org it was really difficult to have a separate group that refused to participate in planning and wanted to design everything up front, optimize based on their performance assumptions, and then who would argue with devs when we'd need to do pretty normal things like, say, list users in a webapp. I'm talking about my experience, not generalizing to all DBAs of course. And of course ORMs introduced performance issues, etc.
  • deleted 2mo ago
    [deleted]
• Waterluvian 2mo ago
  What Python taught me: just use C. These are simply tools. The only wrong opinion is to believe that there’s a strict superiority of one over another. However, the content of this and other blogs can help people make informed decisions on when to reach for each tool.
• Kaliboy 2mo ago
  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?
  • dzonga 2mo ago
    ActiveRecord does have the problem of excess joins though.
• clutter55561 2mo ago
  ORMs have their place but they are leaky as hell. RDMSs are very diverse, have different languages, and require different optimisation techniques. ORMs that try to paper over all the differences fail miserably. They become super complicated and generally produce crap SQL. ORMs also tend to oversimplify database design. They are just tables with primary keys, right? Who needs indices? Who needs to think about collation? God forbid anyone mentions physical organisation of the data! Having said this, I do use a very small subset of SQLAlchemy (the bits I understand) in data pipelines.
• ChicagoDave 2mo ago
  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.
  • zsoltkacsandi 2mo ago
    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.
    • ChicagoDave 2mo ago
      Data consistency was solved in Mongo and DynamoDB years ago. CQRS is a better pattern. Read Models out of analytics (relational) data stores are better for dashboards. I stopped being "SQL First" ten years ago and never looked back. Saved clients time, money, and improved maintenance and eased feature additions.
      • hoppp 2mo ago
        It's sort of about your skills, if you are better at NoSQL then use that. But it doesn't mean that your experience is universal. Relational databases are incredibly flexible even if you have a NoSQL mindset, you can do data modelling like that in Postgres too with jsonb data types.
        • ChicagoDave 2mo ago
          Yes and for crud systems relational is fine because you're unlikely to over-complicated your architecture. But when a system starts talking to other systems and its bounded contexts become complex, alternate solutions should be sought. The problem with "schema change", and I did this for decades, is that it's always a massive blocker. In some companies the data architects had to approve and implement schema changes. You could wait days for that. NoSQL allows you to modify the document surface in mostly non-breaking change ways OR it's easier to version your APIs to handle different document versions. Simple CRUD: Any data store is fine. Complex multiple bounded contexts: Choose the appropriate data store for each bounded context accordingly. My point was no one should be reaching for a relational database or starting with an ERD to build a system. Document behaviors. Model the system. Let the system decide what data storage it requires.
• jdw64 2mo ago
  Use it where it fits, and don't use it where it doesn't. If you don't use an ORM, you'll end up with more boilerplate from mapping code with DTOs. The reason to use an ORM is dirty checking. It's hard to impose this kind of "state" with a relational database. But fundamentally, relational data doesn't fit well with OOP. In the end, you inevitably have to create a layer that absorbs this mismatch. Both approaches have their pros and cons anyway. Isn't it just a matter of using it where it fits and not using it where it doesn't? I wonder if we really have to frame it as "never use this" or "always use that." Actually, on second thought, I take it back. "Right tool for the right place" is harder. If you're on a team, it's probably better to just pick one: either don't use it at all, or use it everywhere. Because either way, friction is going to happen. My earlier thinking was too shallow.
• exabrial 2mo ago
  The purpose of an orm is not to "stop writing SQL". In order to effectively use a layer abstraction, you must be able to use the layer below the abstraction.
• capitainenemo 2mo ago
  I thought this was well put. https://web.archive.org/web/20160301022121/http://www.revision-zero.org/orm-haters-do-get-it https://web.archive.org/web/20160301022121/http://www.revisi... A now defunct site discussing why ORM is a poor map.
• pull_my_finger 2mo ago
  I wonder if the real problem isn't being able to write efficient queries, but that developers struggle to add (yet another) programming language. Just use AWK, just use SQL, just use jq, just use xyz. It's a lot of overhead. I would be OK to lose whatever fractional speed difference to be able to write my queries in a different scripting language. If I ever scaled so much that I needed to shave microseconds off my queries, there are already tons of DBs available, maybe just using a different tool or, even better, compile the DB with(out) different scripting support.
  • bot403 2mo ago
    I can't tell if you're arguing against SQL or orms. But I take your argument in favor of SQL because that's the native language of all the DBS and the dozens of frameworks and systems on top of them are "just use x...."
  • Arch-TK 2mo ago
    There are rather concrete problems that strictly prevent it from being possible to efficiently map graph (object) database access patterns to a relational database. It's not a matter of "fractional speed difference" unless your database has very few entries. OR mismatch problems often like to appear shortly after your database starts to see any real use. The only performant way to use an ORM is to use escape hatches everywhere. Alternatively, you can use an "ORM", something which calls itself an ORM while only doing superficial data mapping into dynamic or generated native (to your language) data structures. There are a _lot_ of these, most normal people call them query generators.
    • AlotOfReading 2mo ago
      There are rather concrete problems that strictly prevent it from being possible to efficiently map graph (object) database access patterns to a relational database. Do you mind going more into that? Naively, it seems like prolog/datalog describe graphs pretty well and they're inherently relational. Relational databases have typically just optimized for row-oriented OLTP uses instead of columnar OLAP, but there's nothing inherent preventing one or the other. They're duals of each other.
• zadikian 2mo ago
  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.
• revetkn 2mo ago
  If you use Java and like to write SQL, check out https://pyranid.com https://pyranid.com I stopped using ORMs around 2008 because they made the easy problems easier and the hard problems harder. I wanted to just write SQL and exploit all the power the DBMS has to offer instead of fighting with an abstraction layer, so I created Pyranid in 2015 and keep it actively updated.
  • deleted 2mo ago
    [deleted]
  • argentinian 2mo ago
    Is it very similar to the relatively new jdbcClient from Spring framework? https://www.danvega.dev/blog/spring-jdbc-client https://www.danvega.dev/blog/spring-jdbc-client
    • revetkn 2mo ago
      Yes - the JdbcClient API has a similar feel for sure. If you are using Spring, it is a better choice than Pyranid because it integrates well with the Spring txn plumbing. Outside of Spring, I think Pyranid has a lot of advantages.
• dools 2mo ago
  I always disliked ActiveRecord, but I figured ORMs don't have to be ActiveRecord. I created this library 14(!) years ago not too long before this article was written https://github.com/iaindooley/PluSQL https://github.com/iaindooley/PluSQL The idea is that you like SQL, but it gets repetitive writing joins and accessor code. I had always hoped it would catch on as a pattern: no boilerplate, automatic mapping to objects in your code of any query (whether generated by the ORM or passed in as a raw query) and easy to override/dynamically build bits of the query as you pass the object around.
  • hparadiz 2mo ago
    That's a query writer. Not an ORM.
    • dools 2mo ago
      No, it's an ORM because it gives you object based iteration over your query (and the ability to use custom classes for those objects, you just don't have to create classes for every single thing if you don't need them). EDIT: oh wait looks like I never got around to implementing the ability to use custom classes :) this is still in the to do section: come up with a good "mix in" style to cast the objects returned from the iterator to a new class for implementing custom functionality (that one would normally include as part of the "boilerplate" class)
      • hparadiz 2mo ago
        You are outputting generic QueryRow classes in your code for all results. That doesn't make it an ORM. By your definition PDO would qualify https://www.php.net/manual/en/class.pdorow.php https://www.php.net/manual/en/class.pdorow.php Here's a full report for you https://gist.github.com/hparadiz/a1fe30e88dbbe070878a7ea4f72bd4ac https://gist.github.com/hparadiz/a1fe30e88dbbe070878a7ea4f72...
        • dools 2mo ago
          No, PDO doesn't qualify, because it lacks the "relational mapping" part. If I want an AI opinion of my project I can always ask a chatbot myself.
• prmph 2mo ago
  I'm not sure why people have not hit on the following hybrid architecture that works so well for me. I make use of table-valued db functions (IMO the most underrated feature of relational DBs) to define virtual relations/tables. I implement a set of CRUD db functions per entity. Then, on the app side, I define (or generate) DTO types representing these virtual relations. Finally, I use a custom ORM I wrote myself, which defines a general and consistent storage API, to talk to the db functions, using the DTO types. The advantages of this approach are numerous, some include: - I have full control of the SQL that goes into constructing the virtual table, I can leverage all the goodness of SQL here. I can even define multiple virtual relations per physical table, or read-only relations, etc, all by implementing the appropriate sets of CRUD db functions - On the ORM side, I have all the goodness of static typing, a consistent API for all CRUD methods, a full fluent query DSL, etc - Since, unlike tables or views, db functions can be passed arguments, i am able to layey all kinds of goodness on top of the basic CRUD actions, like audit info passing, custom upsert strategies, some level of record-based authorization, etc But this architecture does require you to know and write SQL. IMO the value of ORMs do not lie in avoiding SQL; it lies in the capability to express consistent SQL at a higher level of abstraction, but you still need to understand your SQL.
• andrewstuart 2mo ago
  SQL is awesome and you’ll never get the best out of your database unless you learn to program the damn thing and bit hide behind some abstraction. We do programmers always need a library? Program the damn thing.
• nomilk 2mo ago
  > 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.."
• vandahm 2mo ago
  I generally like ORMs but recognize that they have a lot of problems. The most common problem that I've seen is when an ORM makes it easy to select records in a way that looks efficient but really is not. Strictly speaking, this isn't a failure of the ORM itself -- it's the fault of the developer who is using the ORM and also the developer that didn't catch it in code review. But it's a case where the ORM is making work for everyone and obscuring legibility into the code instead of saving time and providing clarity. I've written complicated stuff where an ORM isn't appropriate, but if I'm honest, a large fraction of what I've done in my career is just making boring software to automate menial clerical work, and ORMs are good enough for those kinds of projects.
  • zbentley 2mo ago
    Firmly agree. I wish that ORMs provided two interfaces above raw SQL: a syntactically guaranteed-to-hit-indexes set of functions, and a do-anything set (e.g. MyModel.objects.unrestricted.filter(…)) that you could lint for and audit. An unsung benefit of ORMs is that they have code-level awareness of what queries are likely to be fast, since indexes are usually defined in the ORM. I wish they took more advantage of that.
  • win311fwg 2mo ago
    > Strictly speaking, this isn't a failure of the ORM itself -- it's the fault of the developer You've got that backwards. If a tool obscures complexity such that a developer using it could be tricked into thinking their efficient-appearing code is actually inefficient, the problem is the tool. A well-designed tool makes inefficiencies explicit. "You're holding it wrong" is not engineering advice. > ORMs are good enough for those kinds of projects. It's all good as long as you have properly abstracted it away from your core application. The trouble with some ORM toolkits is that they encourage you to move database logic into the rest of the application and that's when the messes begin. The old school PHP programmers will know well that SQL in raw doesn't automatically mean proper separation of concerns either, but it is more likely to push you in that direction.
• robertclaus 2mo ago
  There are simple "ORM"s that just map classes to tables and columns to attributes. Basically focused on serialization instead of query generation. I find those to be a good balance.
  • globular-toast 2mo ago
    Yeah, you can use SQLAlchemy like this. It's called the data mapper pattern. The bad type is like Django or Rails "Active Record" type ORMs.
• geophile 2mo ago
  I used to love ORMs so much that I built one for Java, in the early 90s, and it was one of the main offerings of a startup that I joined. I have come around 180 degrees. My rethink started when a developer at a Wall Street bank said: having Oracle on my resume is valuable. Having your ORM on my resume is not. And then there’s the “now you have two problems” dynamic. You not only have to write high-performing queries, but you have to get the ORM to generate that query for you. And sometimes you don’t want objects. And the schema mapping has to track schema changes. Just write the damned SQL, it’s not that difficult.
  • runevault 2mo ago
    ORMs are so incredibly finicky. I still remember using old Linq-to-SQL (not Entity Framework) and I had to write the linq query in the reverse order of what I expected or it created 3 nested subqueries instead of just joining the tables together. That was when I learned to instantly double check every ORM query I wrote.
    • sshine 2mo ago
      > Linq-to-SQL (not Entity Framework) and I had to write the linq query in the reverse order I remember those times! Had to write the LINQ, see what it compiled to, redo, until the query was efficient. Abuse LINQ subtleties in how it generated JOIN predicates since it only supported equality. Something about finding an equivalent way of expressing a query with sub-selects that is also computationally equivalent. All so I can get my efficient SQL without writing SQL. So silly.
  • jghn 2mo ago
    > built one for Java, in the early 90s So was your ORM for Oak? Java didn't hit the public sphere until 1995 IIRC
    • geophile 2mo ago
      No it was Java. Sorry, it was late 90s.
• dmeijboom 2mo ago
  My point of view (after 18 years of programming): DO use frameworks (compile-time checked queries if you can) but skip ORMs that hide/obfuscate SQL completely as it will result in slow queries, extra round-trips, etc
  • frollogaston 2mo ago
    I don't even use frameworks. I want my SQL and my regular code to be as close as possible to make it easy to reason about. Like SQL directly inlined with my JS/Py function. Don't need to mentally translate from some query builder to SQL or deal with some native "model" object it converts into. Have never suffered from a wrong-type bug.
• tengbretson 2mo ago
  I don't disagree with any of the major gripes people have with orms and I find SQL to be much cleaner in a lot of circumstances. That being said, if orms didn't force you to explicitly define your domain models about 60% of developers would simply never do it. And you would see differently structured, ad-hoc interfaces defined all over the code base completely entangled with whatever action they are trying to perform. ORMs being a forcing function for domain modeling is enough benefit for me that it outweighs all of their obvious limitations.
  • Kinrany 2mo ago
    I'd rather take a mess of ad-hoc interfaces. Forcing people to do domain modeling does not go well.
    • simondotau 2mo ago
      Pretending that domain modelling is optional does not go well.
      • Kinrany 2mo ago
        Sure, but it's better to do no domain modelling than to pretend doing it.
        • simondotau 2mo ago
          “Doing no domain modelling” is not really an option. It just means the domain model emerges accidentally from ad-hoc interfaces, conditionals, database fields, validation rules, and UI assumptions. Asking an LLM to help with domain modelling isn't ideal, but it's strictly superior to having your model designed by accident, informed primarily by the initial rough draft of your application code.
    • deleted 2mo ago
      [deleted]
  • sandreas 2mo ago
• laszlokorte 2mo ago
  In my opinion Elixir Ecto is ORM done right: 1. the functional/immutable nature of Elixir makes read and writes much more explicit and there is no need to magically track deep mutations of nested objects to translate them back into UPDATE/INSERT queries 2. Elixirs support for lisp-like macros allows for an ergonomic embedded query languages that is syntax and schema checked, mirrors raw SQL really well and, frees you from string-oriented query building 3. the query builder DSL addresses one of the main weaknesses of SQL query statements not being composable 4. The automatic conversion between JOINed tables (on the DB side) and nested structs (on the Elixir side) is done on the right abstraction level to work reliable and and being explicit enough to generate predictable queries.
• vindex10 2mo ago
  It's a bit aside, but what i love about ORM frameworks is that they try to find the universal interface to multiple database backends. For basic CRUD it's nice: test on sqlite deploy wherever.
  • andersmurphy 2mo ago
    That's partly the problem ORMs. Lowest common denominator that prevents you from leveraging a lot of the power of your actual database.
• recursivedoubts 2mo ago
  Why not both? ORMs for the simpler CRUD operations, SQL when it gets a little hectic. The author basically says this in the first paragraph, but the title (and some of the language the author uses) implies that people should just use SQL. It's a reasonable article pointing out some of the annoyances and problems of ORMs (especially in the Java world, where they tend to be overengineered) but there are still a lot of advantages to them if you are in an OO language and they used in a reasonable way.
  • simondotau 2mo ago
    You can optimise your schema to suit your application code, or you can optimise your schema to fit your domain model. Doing the former makes your glue code easier. Doing the latter gives you maximum performance and the maximum querying power of your database engine. You can optimise your schema for the convenience of your application code, or you can optimise it for the truth of your domain model. The former makes glue code easier. The latter gives you stronger constraints, better performance, richer queries, and a database that can answer questions the application code never anticipated.
  • antonvs 2mo ago
    Yes, this is the sensible answer.
• r2ob 2mo ago
  ORM is a great tool for data input. Complex output I always write the old and good raw SQL query.
• Demiurge 2mo ago
  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?
• panny 2mo ago
  >just learn SQL Implying I use an ORM because I don't know SQL... I've reverse engineered embedded databases and written directly to the .dat files on production systems that deal with HIPAA data. I'm pretty sure I know SQL better than most people on HN. I still prefer an ORM. Why? Because with my ORM, I can code gen faster than you can vibe code. I can build on top of the abstraction layer. The data model in the ORM is the M in MVC. The backend could be a SQL database, a file system, a REST service, that part is irrelevant. The M is the same, regardless of the backing store. View and Controller code still works. I find most people who are anti-ORM are kinda junior and trying to flex their power to write SQL scripts as if it is impressive. That's why there's always this weird implying that ORM users don't know SQL.
• pier25 2mo ago
  I was against ORMs until I used EF Core in .NET which I really loved. A good ORM is amazing for productivity and when needed you can always write raw SQL. I don't use .NET anymore but lately I've been happy with Drizzle for TS. It's very performant and expressive. After years it seems that they're finally going to release v1.0 soon. Personally I would never go back to writing all my queries with SQL, manually mapping the results, etc.
  • jkdufair 2mo ago
    I believe efcore is really well designed and handles the ORM tradeoffs in a very usable and mostly efficient way. And someone would have to pry LINQ out of my cold, dead hands. SQL is fine and I'm glad I know it. But I thank god I almost never have to use it.
• nitros 2mo ago
  I really enjoy using Rel8 (https://rel8.readthedocs.io/ https://rel8.readthedocs.io/), so much so that I reimplemented it in Rust (https://github.com/simmsb/rust-rel8 https://github.com/simmsb/rust-rel8). For me I find it's an excellent step up from a plain SQL query builder (with an API such as `select(Foo).join(bar)`) as it lets me both effortlessly perform projections (one can write `(\e -> (e.foo, e.bar) <$> someQuery` to take a query producing rows of `E` and turn it into rows of 2-tuples built from two projected fields. I wrote a bit about my Rust rewrite here: https://bensimms.moe/postgres-lateral-makes-quite-a-good-dsl/ https://bensimms.moe/postgres-lateral-makes-quite-a-good-dsl...
• classified 2mo ago
  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.
• senfiaj 2mo ago
  What's the problem with using ORMs for 95% of the cases and using raw SQL only for the remaining 5% where ORM isn't sufficient? One important benefit (aside from writing less code) of ORMs is type checking which is important for maintainability in large complex projects.
• ralusek 2mo ago
  I have the same response every time I hear this: like 95% of application CRUD plumbing is much better served by an ORM. It gives your application typed versions of your data, lets you work with objects rather than rows, which are almost always more useful, is much easier to read, etc. Then for the 5% of critical/complicated queries: just use SQL there. In fact your ORM almost certainly has an escape hatch for you to do that.
• sulam 2mo ago
  The argument that really hits home for me, after 30+ years in this industry, is stored procedures. The “Stored Procedures are Evil” argument to me is an artifact of an industry that promotes treating engineers and infrastructure as entirely interchangeable and anything that gets in the way of that is Evil(tm). But what working at Salesforce in the 2000’s taught me is that you can do really amazing things if you’re willing to invest heavily in understanding your infrastructure and specializing the hell out of it. Of course that created Oracle lock-in for Salesforce, but that lock-in was the result of Oracle having capabilities that simply didn’t exist elsewhere that Salesforce needed to scale. I would argue Google took that same idea and 100X’d it by building the capabilities they needed when they needed them. In the case of stored procedures, I think if you find yourself fetching huge amounts of data and then doing complex manipulation to it that you can’t do with SQL, consider doing it with stored procedures in the engine and greatly simplifying your application. It may just work out!
  • ahartmetz 2mo ago
    I haven't used stored procedures yet, but even ON DELETE CASCADE is super convenient and I suspect somewhat underused by SQL scaredy cats.
    • wavemode 2mo ago
      ON DELETE CASCADE is horrendously unsafe unless you have full understanding of the entire data model - which is unlikely for the average employee within a large organization with a gigantic database. (And it's also rare to be permanently deleting data when working in such a context, so the convenience doesn't matter that much.)
      • ahartmetz 2mo ago
        It's in the context of "SQLite as local data storage for an application", and I am absolutely sure that entries in a cross-reference table make no sense anymore when one of the linked objects is gone, or entries in an auxiliary data table when the principal object is gone. I am not using ON DELETE CASCADE to be clever - the referenced data is genuinely required.
• wxw 2mo ago
  I agree that "learn SQL" is a necessity, but I'm not sure the article makes a good argument against using ORMs. ORMs are just a layer of abstraction. Like any abstraction, they make some tradeoffs that can get you into some sticky situations like inefficient queries mentioned in the article. But, if you understand the tradeoffs, you can use them for what they're good for (standardization & simplification & in-codebase schema definitions & so on) and usually drop down to SQL whenever there's a particularly necessary case.
• comrade1234 2mo ago
  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.
• hirvi74 2mo ago
  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.
  • sota_pop 2mo ago
    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).
• jeswin 2mo ago
  The problem with ORMs is that they look kludgy without language support - which is why Hibernate in Java looks painful, while DotNet's EF looks like magic. I wrote something similar called TinqerJS - https://tinqerjs.org https://tinqerjs.org, which is like Entity Framework but for TypeScript. There's immense value in everything being typed from the API down to the DB queries. // EF-inspired type-safe API in TypeScript const query = (q) => q .from("users") .where((u) => u.age >= 18 && u.email.includes("@company.com")) .orderBy((u) => u.name) .select((u) => ({ id: u.id, name: u.name, email: u.email })); Of course, ORMs are not for all queries in your project, and may not be a good fit for some projects. That goes without saying. The problem with the article is that it's dismissing ORMs by looking at specific implementations.
• armdave 2mo ago
  > 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.
• vova_hn2 2mo ago
  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.
• jemiluv8 2mo ago
  I’d go with a balanced view: you need them both for any non-trivial product. I was recently reviewing a PR that renamed a model, I wanted to understand what happened under the hood. Turns out that mariadb had a rename table operation forever ago and that was used by the orm under the hood. So no need to backup the prod table. Just run migrate and be done with it. PS: I still exported the table before deploying this fyi.
• nodamage 2mo ago
  People have been making these same arguments for decades and at this point I'm convinced they are all based on the same strawman: That ORM's absolve you from having to learn SQL. Once you understand that was never actually true to begin with you can treat the ORM as a tool that simply helps you generate repetitive boilerplate queries and hydrates result rows back into objects for you. Furthermore, if your objects are long lived (e.g. client-side apps) then ORMs offer you helpful features like identity mapping, unit of work, and change tracking/events. I'm also convinced most of the people poo-pooing on ORMs just haven't worked on problems where these kinds of features are useful. I mean, if you're writing a reporting tool that just queries the database and dumps the result to a table then yeah you might not need an ORM for that. It doesn't mean that ORMs don't solve useful problems for other use cases though.
  • setr 2mo ago
    The problem with ORMs are 1. They pretend SQL is standardized, and support a heavily reduced featureset for any given database as a result 2. They leave awkward holes in their abstraction, leading to psychotic behaviors like N+1 and implicit type coercions to helpfully break your indexes silently 3. They make simple queries simple, and hard queries absolutely revolting 4. You end up not wanting to use the objects directly anyways, so you end up with object-object-relation, needing a mapping layer from your database-object to your business-objects, which also defeats most of the benefits from change-tracking 5. The generated SQL is periodically utterly nuts, so you have to review every generated query anyways 6. You probably dont want to actually use any of the OOP mapping features like inheritance in your DB The correct answer is to use a query builder + database model, enabling most queries to be written with some degree of type-safety, and minimizing the abstraction from SQL itself, and toss out the rest of the featureset
    • bb88 2mo ago
      I have list of issues with SQL. Not composable. Unable to detect query errors at compile time because the schema is only loosely coupled to the code base. And as you yourself point out, SQL is not standardized, which is also terrible and leads to things like Oracle vendor lock in. And frankly this list hasn't changed in 30 or maybe 40 years now. And DBA's were so notoriously egregious that Martin Fowler made his "NoDBA" blog post over a decade ago now. And the movement to NoSQL definitely made things worse. I wish the SQL community would stop treating ORM's like the vietnam paper did 20 years ago, and embrace them for what they are, as a stepping stone, and maybe as a useful tool to help people understand SQL itself.
• dang 2mo ago
  Related: What ORMs have taught me: just learn SQL - https://news.ycombinator.com/item?id=28812506 https://news.ycombinator.com/item?id=28812506 - Oct 2021 (24 comments) What ORMs Have Taught Me: Just Learn SQL (2014) - https://news.ycombinator.com/item?id=24845300 https://news.ycombinator.com/item?id=24845300 - Oct 2020 (291 comments) What ORMs have taught me: just learn SQL (2014) - https://news.ycombinator.com/item?id=21031187 https://news.ycombinator.com/item?id=21031187 - Sept 2019 (634 comments) What ORMs have taught me: just learn SQL (2014) - https://news.ycombinator.com/item?id=15949144 https://news.ycombinator.com/item?id=15949144 - Dec 2017 (348 comments) What ORMs have taught me: just learn SQL (2014) - https://news.ycombinator.com/item?id=11981045 https://news.ycombinator.com/item?id=11981045 - June 2016 (295 comments) What ORMs have taught me: just learn SQL - https://news.ycombinator.com/item?id=8133835 https://news.ycombinator.com/item?id=8133835 - Aug 2014 (234 comments)
  • getnormality 2mo ago
    Seems like we needed an annual meditation on this topic until 2021, then we took a 5 year hiatus? What happened?
  • weiliddat 2mo ago
    I was curious how have sentiments changed over time. Brief LLM-based analysis: https://ampcode.com/threads/T-019f32ac-3b1e-74be-ad63-5f175db93033 https://ampcode.com/threads/T-019f32ac-3b1e-74be-ad63-5f175d... Overall, seems like it got more nuanced over time - even though it's still broadly in favor of SQL. Favor for ORMs (flagged also as a term that can mean many things to different people) is more in terms of type safety, mapping, migrations, etc. so more a library/utility rather than a framework that fully abstracts away the database.
• jiggawatts 2mo ago
  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-ab6708629063/f1.jpg https://dl.acm.org/cms/attachment/feb131ab-37e1-4638-be17-ab...
• bytefish 2mo ago
  What usually happens in my experience is, that a home-grown Data Access Layer usually turns into a bad "ORM light", because materializing results is repetitive and tiring work. You want to abstract it away. As a .NET developer I think EF Core has made the right call here, by allowing you to write SQL where it's needed and still use its infrastructure for all the tedious work of materializing your results. Admittedly in 2014, the time the article was written at, I've also felt using OR-Mapper is a dead-end. But in 2026 the world isn't black and white.
  • drdexebtjl 2mo ago
    I’ve had so many frustrations with EF Core. I always inevitably want to model something in the domain in a way that is not be supported by EF. So I have to maintain EF DTOs and basically give up on the change tracker.
• avereveard 2mo ago
  Mybatis was a thing even back then... you still need a domain model after all
• andy_ppp 2mo ago
  This is one of numerous things Elixir and Phoenix get right with the database layer, which on the surface looks like an ORM but is in fact a set of clever functions that write SQL using Elixir macros, as well as a system for validation and minimal changes to data being passed to said SQL. I’m surprised more languages don’t copy this because it’s exactly what I want rather than loads of complexity that eventually always breaks down.
  • asQuirreL 2mo ago
    > on the surface looks like an ORM but is in fact a set of clever functions that write SQL Honest question -- what's the difference? Usually the problems with ORMs stem from the fact that they are exactly clever functions that write SQL. The cleverness abstracts features of SQL that are important for performance and also makes it easy to do things that are bad for performance. I'm not saying that the ecosystems you mentioned aren't doing something different, I just don't know what it is from how you've described their DB layers.
    • andy_ppp 2mo ago
      No ORMs try to make the concept of SQL hidden, in Elixir you will not get very far if you don’t understand the SQL you’re trying to write. So I’d probably say nothing is really being hidden from you - as little magic as possible. https://ecto.hexdocs.pm/Ecto.Query.html https://ecto.hexdocs.pm/Ecto.Query.html
    • victorbjorklund 2mo ago
      The thing is that in Ecto, everything is structured around the actual underlying data. Rather than some abstract objects and stuff like that. query = from u in User, where: u.age > 18 Repo.all(query) And there is no magic (At least very little). For example, if you wanna access something that is in another table, for example, you're on a user and you wanna access their posts in many frameworks, if you try to read their posts, they would be automatically loaded from the database but in Ecto, you need to explicitly preload them. That avoids accidental and n+1 problems because you can plan your queries more. You're not gonna trigger a lot of queries without realizing it.
• taatparya 2mo ago
  Ecto in Elixir has a decent balance and is nice to use though Elixir doesn't have objects, but the abstraction layer is handy.
• wolfi1 2mo ago
  ORMs do have their use but you can easily screw things up. An anecdote from an university: their was a student administration system where students could themselves enroll to classes. simple enough job, one would guess. but there was a catch: at certain times, usually when more than one student logged in, the system predictably crashed.It turned out, that when a student logged in, a join over 13 tables was performed, even classes the student attended years ago where fetched at the login. These joins were clearly from misconfigured hibernate classes, took them some time to reduce the load on the system
• deleted 2mo ago
  [deleted]
• bazoom42 2mo ago
  Best solution: Learn SQL and understand the relational model. Learn data modelling and normalization. Then choose a good ORM which does not get in the way, but saves a bunch of boilerplate code.
  • simondotau 2mo ago
    An ORM only saves you boilerplate if you’re mapping relationships to objects. And if you’re doing that, you haven’t learned good data modelling and normalisation. ORMs are for storing objects. SQL is for correctly modelled data.
    • gmac 2mo ago
      There's a middle ground between ORMs and raw SQL, especially if you're using a strongly typed language. My library Zapatos[1] is one example among several. [1] https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/
      • simondotau 2mo ago
        That does look like a compelling tool specifically because it isn't really an ORM. It seems more like an ergonomics layer for SQL within that particular language. It looks decent because the database schema remains the source of truth, and the code adapts to it — not the other way around. I think ORMs mostly exist because most programming languages tend to lack an elegant way to write SQL and interact with results. Somewhat ironically, the much-maligned CFML (aka ColdFusion) got this right decades ago. It made SQL string building trivial, and it provided a native data type for tabular query results. No other language I'm aware of has this, and it's the missing piece in many modern ecosystems. They do not need an ORM. They need better ergonomics for interacting with databases: a clean way to compose queries, execute them, and work with the result as structured relational data rather than shoehorning it into application objects.
        • 9rx 2mo ago
          > They do not need an ORM. What you do need is some kind of boundary mapping layer so that your application isn't tightly coupled to the database. That might be a an RRM instead, but if you are going to all the trouble of adding an RRM, why not an ORM? What's the difference, really?
• socketcluster 2mo ago
  ORMs are an anti-pattern. What ends up happening on most projects is that, over time, the ORM ends up generating increasingly complex, inefficient SQL queries behind the scenes. Since some of the people who use the ORM don't understand SQL, they don't realize how inefficient their ORM logic is; it looks like a simple operation from their perspective... It's only if you look under the bonet that you realize that the SQL being generated behind the scenes is a monstrosity. Nobody would have dared write this fugly mass of SQL by hand but from the ORM layer, it looks reasonable... Just a few objects joined by dots....
• ixxie 2mo ago
  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.
• iamflimflam1 2mo ago
  Feels like everyone has to go on the journey. ORMs are bad - I’ll just use SQL. Hmm - I need to map these results onto objects I can use. Hmm - wouldn’t it be great if the object tracked changes and could save itself. I need related/child objects - wouldn’t it be great if I could auto fetch them. …
  • mekoka 2mo ago
    You stopped right before the best part. When they decide to create their own ill designed, badly tested, and undocumented mapper.
  • inigyou 2mo ago
    ultimately, there is no silver shortcut - you just have to write the damn code
    • bartread 2mo ago
      Yeah, exactly. I think the best approach is always to know SQL and know the ORM. Most of the time you’ll be able to simply use the ORM, but every so often you’ll inevitably come up against a situation where a custom query gets the job done better, and you’ll still get the benefits of deserialising to objects that the ORM offers.
      • simondotau 2mo ago
        As long as you restrict yourself to an ORM-compatible schema, you are restricting the power of SQL available to you. Learning SQL properly means learning to model your data correctly, and this usually makes ORMs a non-starter. Without an ORM you have to write a bit more boilerplate code to interact with the database. But by taking advantage of the power of your database engine, you could potentially avoid writing huge amounts of data manipulation logic. In my experience, an ORM is more of a code amplifier than a code simplifier.
        • bartread 2mo ago
• tancop 2mo ago
  [dead]
• ianberdin 2mo ago
  What ORMs have taught me: just do not learn SQL. I don’t for 21 years of coding.
• Dwedit 2mo ago
  ORMs make it hard to write code that allows SQL injection.
• dpedu 2mo ago
  I'm totally on board with the idea that ORMs create a variety of inefficiencies, pain points, and make it really easy to create bad queries or querying strategies. But I use them anyways because the convenience of mapping a row to a code object makes writing programs feel fast and simple. And if you know how ORMs can cause problems and how to watch out for them, you can still get a lot of mileage out of them. That being said, what's the closest alternative that satisfies this - "mapping rows to a code object" - that doesn't suffer the same problems as an ORM? A middle ground between an ORM (like SQLAlchemy, for example) and "your rows are returned as a key/value dictionary where the column names are keys" type approach like Python's DB-API's DictCursor or PHP's mysqli_fetch_assoc. Is there a middle ground here?
  • win311fwg 2mo ago
    No, there is no middle ground. You can either maintain relations throughout the full application or you can transform them into application-native structures, the latter of which is ORM. The article seems to be confusing ORM with query builders. Query builders are where you might avoid writing SQL. ORM is a data transformation technique.
  • bsuvc 2mo ago
    In .NET, I think Dapper comes closest to what you are describing. It does the object mapping, but you still write the queries as SQL. https://github.com/DapperLib/Dapper https://github.com/DapperLib/Dapper
  • taylorlunt 2mo ago
    Yes, there is a middle ground. Elixir's Ecto does this well. Database rows map to structs. But it doesn't try to figure out how to mutate the data for you to keep the struct in sync with the database. All mutations are explicit using changesets (which can also be used for other non-database purposes, like validating user input for an API.) There is no implicit preloading of data. You have to explicitly preload. Data is never fetched implicitly. You have to call Repo.all or Repo.one or something. It has a query DSL that's a thin wrapper over SQL. It's well-designed and I've never had a problem with it.
• scotty79 2mo ago
  Back in the day I made few ORMs for myself exactly because I knew SQL. It's not great.
• ajx1001 2mo ago
  I think there is no one answer for this. In some cases pure SQL is better, in other cases, you need higher level constructs to be efficient, consistent and less error prone. We have lots of experience with ORMs based on dynamic languages (i.e. Objective-C and Ruby) and if not careful, you can indeed go sideways pretty quickly. Recently, we've been using https://ash-hq.org https://ash-hq.org. It tries to solve the same problems as an ORM, but using a pure functional language (Elixir). You are using structs instead of objects, so it can feel very close to using raw dictionaries/hashes. It also makes it super easy to drop down to raw sql, while maintaining that struct interface at the top. While it does take some getting used to (especially coming from a dynamic, OO language), I'm liking this alternative a lot!
• teliskr 2mo ago
  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 :(
• biglost 2mo ago
  I use both. Gorm being my favorurite
• sota_pop 2mo ago
  In my experience, boilerplate sql isn’t even something I would consider a big pain point. The biggest challenge (to me) is explicit data contract enforcement across the stack. I haven’t personally had third-party ORM frameworks succinctly encourage synchronization and help me build against long-term divergence of data models across the stack. “Make it easy to do the right thing and hard to do the wrong thing” still leaves a lot of room for ‘gotchas’ as apps evolve over time. Finally, I don’t understand the aversion in learning even a bit of sql. As topics go, it’s a very good (maybe even the best, if I were being provocative) effort:payoff ratio. Not sure I’d call myself a sql expert, but am always pleasantly surprised how much functionality is within reach by knowing even the very basics of sql.