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

Post by wvenable » Sat, Sep 21, 2019, 2:04 AM UTC

daenz wrote: post #152

wvenable wrote: post #145

Earlier quoted context omitted.

You would need to show me your DDL statements because that's the equivalent. I can generate the model from the database or the database from the model. It's not much more effort to type "create table employees" with all the fixings as it is to type "class employees" with all the fixings.

>I can generate the model from the database or the database from the model. Depends on the ORM. Just like "raw sql mode", not every ORM supports that. It's not an inherent feature of being an object-relational mapper, it's part of the bells and whistles of some ORM packages. And I'm going to guess you're coming from the Python/scripting universe, because generating models in other languages is definitely more complic…

    employee = new Employee() { Name = "Bob" }
    employee.Manager = new Employee() { Name = "Jill" }
    context.Employees.Add(employee)
    context.SaveChanges()

Post by jtdev » Sat, Sep 21, 2019, 2:09 AM UTC

pknopf wrote: post #278

bartread wrote: post #81

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. A…

> 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.

Post by GiorgioG » Sat, Sep 21, 2019, 2:12 AM UTC

danenania wrote: post #332

The way I'd put it is: "learn SQL then use an ORM". If you understand exactly what SQL is being generated and what the implications are, you can use an ORM effectively and benefit from it in many ways (readability, security, composability, etc.). You'll also know when to use it and when it's better to just drop down into SQL. It's when people don't really know what the ORM is doing underneath that they get in trouble…

Post by notyourday » Sat, Sep 21, 2019, 2:14 AM UTC

lugg wrote: post #288

dymk wrote: post #246

Earlier quoted context omitted.

But you shouldn’t live with a hand-rolled pseudo ORM that stumbled into existence when there’s developed alternatives

Why not? I've used hand rolled pseudo ORMs before. I prefer just plain SQL but for the application I had there was a common access pattern that was worth abstracting out in a DRY sense. That doesn't mean I want or need a complete ORM. Just a consistent access at certain table types.

Post by jtdev » Sat, Sep 21, 2019, 2:17 AM UTC

Daishiman wrote: post #214

acd wrote: post #60

Will tend to agree with the author. Initially ORMs can save time when developing as you get an easy mapping between objects and the database. However in practise ORM tends to give you quite horrible JOINs that quite frankly are hard to understand for humans. Further more I think that ORM can lead to a bad practice in the sense that you do not need to think about your data layout first. But for database performance da…

This is completely false. The joins I do in the ORM are completely transparent to me as a developer and there is no mismatch whatsoever. The data layout and data migrations are well described. And I have, at most, a half dozen difficult queries which require serious optimization, and that optimization isn't defined by the query but by the indexing and storage strategy for the tables in question.