The main reason people want to use ORMs is when using fully normalized parent-child tables more than a couple of levels deep. It is a legitimate pain to translate a decently nested object into relational tables and back. And ORMs can help you there.
However, I still feel the cost of being locked into an ORM's abstractions is too high in the long run. In those kinds of cases where I need to load and store a nested object graph as a single unit, I will just serialize it and store it in a single column. In Postgres you can even index and query on this kind of data when stored as JSON (with a column type jsonb).
I will use a so-called "micro ORM" in typed languages, which maps a row to an object. But I still write the SQL that returns the rows in the first place.
Take what I am saying with a grain of salt though. We make different trade-offs lately which avoids needing complex SQL queries in most cases. (We just replay facts into a new table to answer a different question.) But we pay for it with some architectural complications. Do what is best for your situation. :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The main reason people want to use ORMs is when using fully normalized parent-child tables more than a couple of levels deep. It is a legitimate pain to translate a decently nested object into relational tables and back. And ORMs can help you there.
However, I still feel the cost of being locked into an ORM's abstractions is too high in the long run. In those kinds of cases where I need to load and store a nested object graph as a single unit, I will just serialize it and store it in a single column. In Postgres you can even index and query on this kind of data when stored as JSON (with a column type
jsonb).I will use a so-called "micro ORM" in typed languages, which maps a row to an object. But I still write the SQL that returns the rows in the first place.
Take what I am saying with a grain of salt though. We make different trade-offs lately which avoids needing complex SQL queries in most cases. (We just replay facts into a new table to answer a different question.) But we pay for it with some architectural complications. Do what is best for your situation. :)