3 ms·

It depends what you're doing with the data. If you're trying to map into an object based view of your data, then yes ORMs have at least thought of most of the i

It depends what you're doing with the data. If you're trying to map into an object based view of your data, then yes ORMs have at least thought of most of the issues there. However if you'd like to view your relational data gasp relationally, then the ORM is a giant anchor around your neck.

BiteCode_dev 5y ago
Good orms like sqla comes in layers, and the object relationships mapping is the highest one. You can use lower level layers as you need, and retain the benefit of a strong battle tested abstraction that gives you introspection and a standard API. Sometimes I use sqla just for the connection pool and session handling and dump raw sql in it. It's not raw sql vs orm, as usual it's use a spectrum with good use cases for each part of it, and you usually benefit from all of it. But orm have pareto value in my xp.
- blacktriangle 5y ago
  ORMs only have value IF there's an object model you're mapping to. When working in a language that has good support for relational data, ie support for sets of heterogeneus maps, you can skip the whole object model and avoid the whole need for mapping in the first place. Ruby and Python in particular really missed the boat on this one. I feel like they cargo culted practices from Java rather than embrace the implications of their own langauge's flexibility.
  - ad404b8a372f2b9 5y ago
    Isn't that what pandas does kind of? You can execute sql queries and get the results in a dataframe which is a dictionary with some convenience functions on top. Do you feel python could have gone further to take advantage of specific language features to improve that workflow?
    - blacktriangle 5y ago
      I was more taking shots at Django. pandas is a great example of doing things right imo and me ripping on python at large was more my web-dev myopia shining through.
  - spfzero 5y ago
    Right, OOP is sometimes not the best paradigm for the given problem. If you're using C# or Java, sure, ORMs fit right in. Ruby and Python, not to mention Lisp etc., offer a multi-paradigm palette where forcing objects in, just to access relational data, just obscures things.
- ziml77 5y ago
  I guess a lot of people haven't seen the middle-ground. For me that's always been where I've sat with ORMs. It takes care of some tedious parts of getting data from SQL into my application without pretending that the underlying data isn't relational. SQLAlchemy and Dapper (.NET) have been great for this middle-ground usage.
  - jrockway 5y ago
    I personally prefer something like sqlx, where you just scan rows into structs. That's the tedious part of object-relational mapping, and the part that actually makes sense to automate. Generally, I think what people call ORMs try to do too much, and there is an impedance mismatch on many levels. Objects and relations don't map; objects are statically-defined at program compilation time, and relations are the result of a dynamic query. I think the reason that ORMs work in dynamic languages is that there isn't a rigid set of objects defined by the program; rather they can come and go during execution. So the problem becomes a problem later -- static analysis, editor tooling, etc. Lifecycles are also complicated. You can have your ORM return dumb objects that you modify and re-store, or they can be "smart" and updated the database automatically. The "dumb object" approach neglects database transactions (multiple writers could have already modified your cached copy), and the "smart" approach neglects the networked nature of your SQL server (you may need to retry, you may need to time out if the server goes down, etc.) by pretending that some server run by another company is actually your CPU's cache. Finally, I think it's very optimistic to write an application to support more than one database backend, which seems to be everyone's dream. Many have tried. Few have succeeded. I chalk it up as actually being O(n) work to support n databases. MySQL has some quirk that breaks Postgres's assumptions. Even the humble SQLite is different enough that is hard work to support as a secondary / test-only implementation. (I realized this, I think, when I debugged some code that worked in tests, but not in production. The tests used SQLite and did something like "insert into foo (boolean_value=1); select * from foo where boolean_value='t'". In Postgres, the inserted object is selected. In SQLite, it's not! That, to me, was the end of ever supporting two databases without the explicit requirement to do so. I'd still run my Postgres tests against Postgres and my SQLite tests against SQLite, though.) All in all, I don't get it. Start a transaction, scan into a struct, mutate the object, write it back to the database. Not much code is required. If your mutation operation is too long to run in a transaction (i.e., it reaches out to the network for something), then you really need a state machine, which you can easily implement in your relational data model.
Scarbutt 5y ago
What is wrong with viewing the data relationally?
- blacktriangle 5y ago
  Nothing at all, I'd argue working with relational data relationally is ideal. It was in response to the statement that anybody try to do their own data access layer is guilty of hubris. I'd say the bigger hubris is trying to shove relational data into object graphs and the challenges and pain of ORMs is proof of that.
  - gabereiser 5y ago
    It’s important to know the difference between a DAO and a DAL in my comment. Many are confusing the two.
notJim 5y ago
> However if you'd like to view your relational data gasp relationally, then the ORM is a giant anchor around your neck. How so? I've never found this to be the case.

BiteCode_dev 5y ago

Good orms like sqla comes in layers, and the object relationships mapping is the highest one. You can use lower level layers as you need, and retain the benefit of a strong battle tested abstraction that gives you introspection and a standard API. Sometimes I use sqla just for the connection pool and session handling and dump raw sql in it. It's not raw sql vs orm, as usual it's use a spectrum with good use cases for each part of it, and you usually benefit from all of it. But orm have pareto value in my xp.

blacktriangle 5y ago
ORMs only have value IF there's an object model you're mapping to. When working in a language that has good support for relational data, ie support for sets of heterogeneus maps, you can skip the whole object model and avoid the whole need for mapping in the first place. Ruby and Python in particular really missed the boat on this one. I feel like they cargo culted practices from Java rather than embrace the implications of their own langauge's flexibility.
- ad404b8a372f2b9 5y ago
  Isn't that what pandas does kind of? You can execute sql queries and get the results in a dataframe which is a dictionary with some convenience functions on top. Do you feel python could have gone further to take advantage of specific language features to improve that workflow?
  - blacktriangle 5y ago
    I was more taking shots at Django. pandas is a great example of doing things right imo and me ripping on python at large was more my web-dev myopia shining through.
- spfzero 5y ago
  Right, OOP is sometimes not the best paradigm for the given problem. If you're using C# or Java, sure, ORMs fit right in. Ruby and Python, not to mention Lisp etc., offer a multi-paradigm palette where forcing objects in, just to access relational data, just obscures things.
ziml77 5y ago
I guess a lot of people haven't seen the middle-ground. For me that's always been where I've sat with ORMs. It takes care of some tedious parts of getting data from SQL into my application without pretending that the underlying data isn't relational. SQLAlchemy and Dapper (.NET) have been great for this middle-ground usage.
- jrockway 5y ago
  I personally prefer something like sqlx, where you just scan rows into structs. That's the tedious part of object-relational mapping, and the part that actually makes sense to automate. Generally, I think what people call ORMs try to do too much, and there is an impedance mismatch on many levels. Objects and relations don't map; objects are statically-defined at program compilation time, and relations are the result of a dynamic query. I think the reason that ORMs work in dynamic languages is that there isn't a rigid set of objects defined by the program; rather they can come and go during execution. So the problem becomes a problem later -- static analysis, editor tooling, etc. Lifecycles are also complicated. You can have your ORM return dumb objects that you modify and re-store, or they can be "smart" and updated the database automatically. The "dumb object" approach neglects database transactions (multiple writers could have already modified your cached copy), and the "smart" approach neglects the networked nature of your SQL server (you may need to retry, you may need to time out if the server goes down, etc.) by pretending that some server run by another company is actually your CPU's cache. Finally, I think it's very optimistic to write an application to support more than one database backend, which seems to be everyone's dream. Many have tried. Few have succeeded. I chalk it up as actually being O(n) work to support n databases. MySQL has some quirk that breaks Postgres's assumptions. Even the humble SQLite is different enough that is hard work to support as a secondary / test-only implementation. (I realized this, I think, when I debugged some code that worked in tests, but not in production. The tests used SQLite and did something like "insert into foo (boolean_value=1); select * from foo where boolean_value='t'". In Postgres, the inserted object is selected. In SQLite, it's not! That, to me, was the end of ever supporting two databases without the explicit requirement to do so. I'd still run my Postgres tests against Postgres and my SQLite tests against SQLite, though.) All in all, I don't get it. Start a transaction, scan into a struct, mutate the object, write it back to the database. Not much code is required. If your mutation operation is too long to run in a transaction (i.e., it reaches out to the network for something), then you really need a state machine, which you can easily implement in your relational data model.

Scarbutt 5y ago

What is wrong with viewing the data relationally?

blacktriangle 5y ago
Nothing at all, I'd argue working with relational data relationally is ideal. It was in response to the statement that anybody try to do their own data access layer is guilty of hubris. I'd say the bigger hubris is trying to shove relational data into object graphs and the challenges and pain of ORMs is proof of that.
- gabereiser 5y ago
  It’s important to know the difference between a DAO and a DAL in my comment. Many are confusing the two.

notJim 5y ago

> However if you'd like to view your relational data gasp relationally, then the ORM is a giant anchor around your neck. How so? I've never found this to be the case.