4 ms·

Ah yes - the proverbial "ORMs are bad, just learn SQL" post. This is analogous to saying "don't use frameworks". Sound ridiculous? Yes, yes it is. The law of l

Ah yes - the proverbial "ORMs are bad, just learn SQL" post. This is analogous to saying "don't use frameworks". Sound ridiculous? Yes, yes it is. The law of leaky abstractions applies to many, many things, ORMs included. I would also argue they apply in different degrees, usually related to the design of the ORM (the post mentions SQLAlchemy vs. Hibernate, for example). But consider the following: 1) Why do people still use ORMs? Exactly. 2) Question 1 but s/ORM/framework_or_widely-used-library 3) ORMs allow you to develop faster, and deliver value 4) Beginners already have a hard time coding, designing, and understanding what they're doing. ORMs provide a nice abstraction over underlying data stores 5) Although fraught with peril, ORMs provide a common interface that'd give _some_ help if you switch data stores 6) Multi-line SQL statements are a huge pain in some languages

eru 9y ago
ORMs are bad, because objects aren't particularly useful to deal with most data. And when you've already been through the effort to make your data relational for the database, might as well re-use that effort. That's not to say that SQL is the answer. Proper first class support for relations in your programming language / libraries is great. As for using a DSL, Datalog is worth a look.
- 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 ago
    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 endemic.
    - wvenable 9y ago
      I 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 ago
    But 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 ago
      How 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 ago
        I 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 ago
        I 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.
BigJono 9y ago
In response to (4). I'd posit that beginners have a hard time with this stuff because they use too many leaky abstractions. Like the article says, if you want to use an ORM for anything non-trivial, you need to learn both the ORM and SQL, which is inherently more difficult than just learning SQL. Providing tons of abstractions to beginners so they can build something in 10 lines of code doesn't help them get better. All it does is encourage them to learn top-down when it's often much easier to learn something from the bottom-up.
atsjie 9y ago
> This is analogous to saying "don't use frameworks". Sound ridiculous? Yes, yes it is. When developing API's in Golang or for microservice / serverless architectures not using a framework might actually make a lot of sense. Also microframeworks (trimmed-down versions compared to opinionated frameworks) are very popular in almost any language.
- ldarcyftw 9y ago
  There are such things as micro-ORM as well, btw. Still an ORM though.
- icebraining 9y ago
  I'd say that Golang rather comes with a (simple) framework in the standard library, so you don't need a third-party one. After all, http.Handle/HandleFunc clearly follow the Hollywood Principle: http://wiki.c2.com/?HollywoodPrinciple http://wiki.c2.com/?HollywoodPrinciple
jayd16 9y ago
By this logic, no bad practices exist.

eru 9y ago

ORMs are bad, because objects aren't particularly useful to deal with most data. And when you've already been through the effort to make your data relational for the database, might as well re-use that effort. That's not to say that SQL is the answer. Proper first class support for relations in your programming language / libraries is great. As for using a DSL, Datalog is worth a look.

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 ago
  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 endemic.
  - wvenable 9y ago
    I 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 ago
  But 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 ago
    How 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 ago
      I 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 ago
        I 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.

BigJono 9y ago

In response to (4). I'd posit that beginners have a hard time with this stuff because they use too many leaky abstractions. Like the article says, if you want to use an ORM for anything non-trivial, you need to learn both the ORM and SQL, which is inherently more difficult than just learning SQL. Providing tons of abstractions to beginners so they can build something in 10 lines of code doesn't help them get better. All it does is encourage them to learn top-down when it's often much easier to learn something from the bottom-up.

atsjie 9y ago

> This is analogous to saying "don't use frameworks". Sound ridiculous? Yes, yes it is. When developing API's in Golang or for microservice / serverless architectures not using a framework might actually make a lot of sense. Also microframeworks (trimmed-down versions compared to opinionated frameworks) are very popular in almost any language.

ldarcyftw 9y ago
There are such things as micro-ORM as well, btw. Still an ORM though.
icebraining 9y ago
I'd say that Golang rather comes with a (simple) framework in the standard library, so you don't need a third-party one. After all, http.Handle/HandleFunc clearly follow the Hollywood Principle: http://wiki.c2.com/?HollywoodPrinciple http://wiki.c2.com/?HollywoodPrinciple

jayd16 9y ago

By this logic, no bad practices exist.