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

Post by wvenable » Mon, Dec 18, 2017, 5:56 AM UTC

amarkov wrote: post #102

wvenable wrote: post #84

Earlier quoted context omitted.

> ORMs are bad, because objects aren't particularly useful to deal with most data. Objects are containers of data; that's a crazy statement to make. The relational structure maps pretty cleanly to objects, properties, and collections. However, objects are not good for reporting. And the author mentioned doing 14 joins and hundreds of columns - that smells like a reporting query.

The relational structure maps cleanly to badly designed objects, where most classes have 5-10 fields and most fields are opaque data values with setters and getters. If you wrote classes like that in isolation, you'd have to do some serious work in code review, explaining why a hodgepodge collection of properties is a single unit of responsibility. But I've never worked in an ORM-using system where they weren't endem…

Post by dragonwriter » Mon, Dec 18, 2017, 5:59 AM UTC

Merad wrote: post #108

Someone1234 wrote: post #20

Earlier quoted context omitted.

LINQ isn't a ORM. I assume you mean Entity Framework? EF definitely has the foreign key issue. We have around a thousand tables, we tried to generate the classes for all of them including foreign keys, problem is that when you create a context that references even only a single table, it will load everything that is foreign keyed including siblings of siblings of siblings, until you run out of memory. Only way around…

Were you doing serialization or something like that that recursively accessed all of the properties in the model? If so, and if lazy loading was turned on (the unfortunate default) then the serializer would indeed keep exploring the object graph until it either loaded your whole database or hit OOM. That's about the only scenario I can think of that would cause such an issue - EF doesn't eagerly load related entities…

Post by jgeraert » Mon, Dec 18, 2017, 6:01 AM UTC

3riverdev wrote: post #73

(Bias: I'm one of the Hibernate ORM committers.) Hibernate (and presumably any ORM) was never intended to be a complete abstraction of anything-SQL. Like others have mentioned here, an understanding of SQL must be had before using an ORM. The ORM is one piece to the puzzle, not a shield to prevent you from having to touch SQL. One pattern I typically use is a take on CQRS: Hibernate for writing/updating/fetching/dele…

Post by int_19h » Mon, Dec 18, 2017, 6:04 AM UTC

eru wrote: post #82

jeswin wrote: post #77

Earlier quoted context omitted.

LINQ is not an ORM. My examples were showing easy, lazy evaluation. My C# is rusty, but the examples mostly hold I think. The following gets executed on iteration (of expensiveOrders), the lambda is compiled into a Function and run on each item in orders: IEnumerable orders = ...; const expensiveOrders = orders.Where(o => o.total > 100) The following gets compiled into an expression tree, which an ORM can analyze and…

Thanks. My quip was just that objects (as in object-oriented-programming) aren't the right abstraction. Having some kind of mapper in your language between the database and the entities your program is dealing with is useful, and you showed that functional programming is a more friendly host than oop. (Logic programming might also be workable?)

   var r = customers.Select(c => new { cust = c, orders = c.Orders })

Post by esfandia » Mon, Dec 18, 2017, 6:06 AM UTC