3 ms·
> 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 relat
by wvenable 9y ago
> 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.
- amarkov 9y agoThe 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 endemic.
- wvenable 9y agoI don't buy into the idea that those kind of classes are just unqualified bad design. The majority of applications exist to merely to store information entered by users. Using a class to hold that data in a structured and type-checked way is perfectly reasonable. And they aren't a hodgepodge collection of properties; they're entities that represent a single item in a system whether that be a person, a widget, an order, or a product.
- dragonwriter 9y ago> The relational structure maps cleanly to badly designed objects If you are exposing base tables to the application instead of appropriate views, which as much a violation of good RDBMS design principles as what you describe is a violation of good OO design.
- zkomp 9y agoBut why do you need these containers of data, when you could have more direct access to both the data itself and the whole set (not individual objects, nor collections of objects) I dont like ORMs but did struggle some years trying to use them which imho was a detour. SQL and stored procedures in plpgsql is so much better, easier to maintain, easier to reason about etc.
- icebraining 9y agoHow would you calculate the average of the sum of three columns (AVG(A + B + C)) which are chosen by the user at runtime?
- zkomp 9y agoI personally would write a simple plpgsql stored procedure, but I would not trust user input and only allow a defined set of colums from a defined set of tables. you can have lots of dynamic sql but that might become a rabbithole, just as with an ORM. It sounds like a problem you shouldnt have, now throwing an ORM at such a problem... might lead to even more strange issues down the road...
- icebraining 9y agoI personally would write a simple plpgsql stored procedure, but I would not trust user input and only allow a defined set of colums from a defined set of tables. Sure, you can limit it to a single table and to a certain set of columns e.g. A B C D E. Can you give me an example of a simple plpgsql stored procedure to do this? you can have lots of dynamic sql but that might become a rabbithole, just as with an ORM That's not my experience. In a language with good introspection and/or where most entities are first-class, you can do this rather easily. In Python that would take two or three short lines. It sounds like a problem you shouldnt have This is a bit of a cop-out :) allowing the generation of simple reports configured by the user is a typical need for us.