Initially ORMs can save time when developing as you get an easy mapping between objects and the database.
However in practise ORM tends to give you quite horrible JOINs that quite frankly are hard to understand for humans.
Further more I think that ORM can lead to a bad practice in the sense that you do not need to think about your data layout first.
But for database performance data layout is of utter most importance. One need to have data in lay out in a form that makes the application run
fast. ORMs does not necessarily provide that. One need to normalize the database.
ORM save you time during initial development but you pay later in the maintenance phase when what is complex queries that humans may not understand are hard to optimize for performance.
This is completely false. The joins I do in the ORM are completely transparent to me as a developer and there is no mismatch whatsoever. The data layout and data migrations are well described.
And I have, at most, a half dozen difficult queries which require serious optimization, and that optimization isn't defined by the query but by the indexing and storage strategy for the tables in question.
> The joins I do in the ORM are completely transparent to me as a developer and there is no mismatch whatsoever.
Care to provide any examples with comparisons to ANSI SQL or any major SQL platform?
*take note that “SQL became a standard of the American National Standards Institute (ANSI) in 1986, and of the International Organization for Standardization (ISO) in 1987.” the same cannot be said for any ORM.
How many of these are a result of of features that have nothing to do with getting data in and out of the database.
Get bare metal. Anything caked on adds friction.
That doesn't mean "write raw SQL". That means I want just enough of an ORM to give me type-safety for my queries and updates. Leave the rest at the door.
Initially ORMs can save time when developing as you get an easy mapping between objects and the database.
However in practise ORM tends to give you quite horrible JOINs that quite frankly are hard to understand for humans.
Further more I think that ORM can lead to a bad practice in the sense that you do not need to think about your data layout first. But for database performance data layout is of utter most importance. One need to have data in lay out in a form that makes the application run fast. ORMs does not necessarily provide that. One need to normalize the database.
ORM save you time during initial development but you pay later in the maintenance phase when what is complex queries that humans may not understand are hard to optimize for performance.
Database normalization https://en.wikipedia.org/wiki/Database_normalization https://en.wikipedia.org/wiki/Third_normal_form