4 ms·

If you've already learned SQL and are comfortable using it directly, do you think there is any reason that it'd be wrong to continue doing so?

• zzzeek 14y ago
  it's really not as much about the querying (though there is a lot of time-saving automation to be had there) as it is about integrating the data in your object model with the tuples being shuttled to/from the database. Like, at what point do you get sick of writing redundant "INSERT INTO <table>" over and over again? Are there really people who still don't see the time-wasting, code-cluttering repetition in that?
  • silverbax88 14y ago
    I'm still amazed that there are developers who would rather spend more time maintaining/debugging/optimizing ORM code in a mature app that just learning a simple INSERT statement.
    • d23 14y ago
      Because in my experience, the "maintaining/debugging" step is almost non-existent (isn't that the point of the ORM?), and the "optimizing" step hasn't been an issue for the traffic our sites get.
      • papsosouid 14y ago
        > the "maintaining/debugging" step is almost non-existent (isn't that the point of the ORM?) Nobody can agree on the point of ORMs, which is a large part of the reason why there's so much debate over whether to use them and how. I must say, if their point is to eliminate maintenance and debugging, then they are failing miserably at it.
    • untog 14y ago
      who would rather spend more time maintaining/debugging/optimizing ORM code But that's kind of the point- with a decent ORM library there isn't really much work to do. model = MyModel.load(id) Add a new field to your model? It'll handle it. It might even modify the table for you. With raw SQL you'd have to go and edit your UPDATE and INSERT statements each time. Seems like a lot more maintenance/potential debugging to me.
      • silverbax88 14y ago
        Okay, add a messaging trigger on update and insert between two joined permission tables, without creating a mutating trigger. SQL is about a lot more than CRUD and tables.
        • zzzeek 14y ago
          so add a trigger to your tables. How is an ORM getting in the way of that?
        • untog 14y ago
          SQL is rarely about a lot more than CRUD and tables. I would think that over 95% of the SQL code ever written has been CRUD operations. ORMs exist to simplify CRUD operations. If you are trying to do something that is a not a CRUD operation then you'd be mad to try and use an ORM to do it.
• PleaseBeSerious 14y ago
  If you already have a layer of abstraction to your SQL statements, then it can be arguable. But if your are littering SQL statements everywhere, making changes to the database can be more tedious. Also if you want to support more than one type database, I would use an ORM.
• malkia 14y ago
  Other people on your team, might not be on the same SQL level as you. E.g. you can create very fast update/bulk/etc. operations directly in your used SQL engine, but then provide some ORM for people not familiar so that they can get access (speed might not be critical to them, just access to the db). An example - in the game industry we often have technical artists - pretty cool bunch of folks with awesome talents - art (maya, motionbuilder, etc.) and coding (python, mel, C/C++) - these folks are never afraid to step into the dark woods, and would take SQL and learn it as if it was nothing dangerous, but they surely won't mind a good ORM. From what I've learned, they see most of these things as tools.
• jrochkind1 14y ago
  Any reason it would be 'wrong'? There are few things in software engineering that are universally 'right' or 'wrong', it all depends on context. There are plenty of people who already know SQL and are comfortable using it, but still prefer to use an ORM though. It's not like ORMs are only used or liked by people who don't know SQL.
  • tjr 14y ago
    Fair enough. Replace "wrong" with "generally considered a suboptimal idea".
    • jrochkind1 14y ago
      Still, 'it depends'. Yeah, there are all sorts of reasons, depending on context (and plenty of people to argue all those reasons). Personally, I agree with OP that nobody should ever use an ORM as an excuse to not know SQL. You need to know SQL anyway. So, once we agree on that, your question "Is there any reason to use an ORM if I know SQL" (that's basically what you mean when you phrase it in the inverse "Is there any reason it would be suboptimal to NOT use an ORM", right?) -- basically just boils down to "Is there ever any reason to use an ORM?". A topic which is basically the equivalent editor/OS war of db-based web development on HN or reddit. Meaning it's an argument that can and does go on forever, and you can find in-depth treatments of in many other threads.
      • tjr 13y ago
        Thank you. I believe my question has been answered, even if I failed at expressing it the way I intended.