Disclaimer: My experience comes from ~8 years ago, but ORMs were commonplace even that time. Not sure what improvement happened since.
An ORM framework gives you a false promise: that you can forget (or not even be much aware of) that you are working with a DB, and just continue using objects the way you normally would in your programming language (my experience was from Java).
That is a lie, and lies will come to hurt you eventually. Some specific examples that hurt me back then:
The promise that it is easy (no fiddling with schema, DB connections, whatever). Initial wiring is always a hassle - getting the configs right, getting JPA to register correctly, getting the annotations right. Not as worry-free as expected.
Leaky abstraction. For example, when you commit new objects to the DB the first time, their identity changes (see developer.jboss.org/wiki/EqualsAnd...).
Where are transaction boundaries? If db objects mix with regular objects and get passed around in code, it is easier to loose track of what is committed or not (or when). Usually what you want is doing logic upfront, then having a tight section where you make a transaction.
Limited performance. The ORM can't do as sophisticated query optimization as the DB can.
Unexposed DB functionality. Eventually you might need something from the DB that the ORM doesn't expose.
My choice is having a DB access layer, which exposes high-level operations to the user code, but implements db access using SQL directly. I believe it is a low-friction and clear solution.
I never got the idea with MongoDB and friends. My impression was, a lot of bloggers trying to push this new thing, that would make everything much easier.
Every time I came in touch with something ORM, it only blurred the hole data model, and I'd be looking for a way to migrate this thing into a normalized SQL database.
I grew my database bones with mSQL -> MySQL so my opinion might be colored by that :)
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.
Disclaimer: My experience comes from ~8 years ago, but ORMs were commonplace even that time. Not sure what improvement happened since.
An ORM framework gives you a false promise: that you can forget (or not even be much aware of) that you are working with a DB, and just continue using objects the way you normally would in your programming language (my experience was from Java).
That is a lie, and lies will come to hurt you eventually. Some specific examples that hurt me back then:
The promise that it is easy (no fiddling with schema, DB connections, whatever). Initial wiring is always a hassle - getting the configs right, getting JPA to register correctly, getting the annotations right. Not as worry-free as expected.
Leaky abstraction. For example, when you commit new objects to the DB the first time, their identity changes (see developer.jboss.org/wiki/EqualsAnd...).
Where are transaction boundaries? If db objects mix with regular objects and get passed around in code, it is easier to loose track of what is committed or not (or when). Usually what you want is doing logic upfront, then having a tight section where you make a transaction.
Limited performance. The ORM can't do as sophisticated query optimization as the DB can.
Unexposed DB functionality. Eventually you might need something from the DB that the ORM doesn't expose.
My choice is having a DB access layer, which exposes high-level operations to the user code, but implements db access using SQL directly. I believe it is a low-friction and clear solution.
Besides, writing huge joins is fun!
I never got the idea with MongoDB and friends. My impression was, a lot of bloggers trying to push this new thing, that would make everything much easier.
Every time I came in touch with something ORM, it only blurred the hole data model, and I'd be looking for a way to migrate this thing into a normalized SQL database.
I grew my database bones with mSQL -> MySQL so my opinion might be colored by that :)