4 ms·

There's a sensible middle ground here, although I agree with the thrust of the message because using an ORM doesn't obviate the need to learn SQL - something I

There's a sensible middle ground here, although I agree with the thrust of the message because using an ORM doesn't obviate the need to learn SQL - something I think a lot of developers forget. The other extreme from using an ORM "for everything" is using SQL "for everything", either via loads of handwritten ad hoc SQL, or stored procedures, UDFs, views, or a mix of all of these. This is just a different nightmare. And don't be fooled: it really is still a nightmare. A sensible approach blends use of an ORM with handwritten SQL where needed. In fact most ORMs will allow you to do things like build collections of objects from custom SQL anyway, so there's really no need to shy away from it. One other thing I'd say: I wouldn't necessarily trust my ORM to adequately design my database for me via a code first approach. It's more work but thinking about the data model and explicitly designing the database often yields better results, and you have more control. Code first is OK for simple stuff, but often even simple stuff becomes complex over time so I tend to shy away from it.

pknopf 7y ago
> A sensible approach blends use of an ORM with handwritten SQL where needed. In fact most ORMs will allow you to do things like build collections of objects from custom SQL anyway, so there's really no need to shy away from it. This is really where it's at. Seriously people. Nobody should be writing raw SQL. Give me just enough of an ORM/abstraction to give me type-safety, leave the rest at the door.
- jtdev 7y ago
  > Nobody should be writing raw SQL. What?!? That’s an absolutely foolish and naive assertion. Please don’t give any of your fellow junior devs that “advice”...
  - pknopf 7y ago
    Are you advocating that I put a bunch of magic strings in my codebase? That would be a maintenance nightmare. Unless you think I'm suggesting that no devs should ever write SQL at all in their career? Which isn't the case.
    - shkkmo 7y ago
      > Are you advocating that I put a bunch of magic strings in my codebase? That would be a maintenance nightmare. Not a bunch, just the large batch queries and reports that use complicated joins. There a places where it makes sense to take the trade-off between maintainability and performance. > Unless you think I'm suggesting that no devs should ever write SQL at all in their career? Which isn't the case. It sure appears to be what you are suggesting. Perhaps you should clarify what you were trying to say?
- pleasecalllater 7y ago
  > This is really where it's at. Seriously people. Nobody should be writing raw SQL. I think nobody should be writing comments here. They should be generated by some tool. So, please, be serious. :)

pknopf 7y ago

> A sensible approach blends use of an ORM with handwritten SQL where needed. In fact most ORMs will allow you to do things like build collections of objects from custom SQL anyway, so there's really no need to shy away from it. This is really where it's at. Seriously people. Nobody should be writing raw SQL. Give me just enough of an ORM/abstraction to give me type-safety, leave the rest at the door.

jtdev 7y ago
> Nobody should be writing raw SQL. What?!? That’s an absolutely foolish and naive assertion. Please don’t give any of your fellow junior devs that “advice”...
- pknopf 7y ago
  Are you advocating that I put a bunch of magic strings in my codebase? That would be a maintenance nightmare. Unless you think I'm suggesting that no devs should ever write SQL at all in their career? Which isn't the case.
  - shkkmo 7y ago
    > Are you advocating that I put a bunch of magic strings in my codebase? That would be a maintenance nightmare. Not a bunch, just the large batch queries and reports that use complicated joins. There a places where it makes sense to take the trade-off between maintainability and performance. > Unless you think I'm suggesting that no devs should ever write SQL at all in their career? Which isn't the case. It sure appears to be what you are suggesting. Perhaps you should clarify what you were trying to say?
pleasecalllater 7y ago
> This is really where it's at. Seriously people. Nobody should be writing raw SQL. I think nobody should be writing comments here. They should be generated by some tool. So, please, be serious. :)