3 ms·
Will tend to agree with the author. Initially ORMs can save time when developing as you get an easy mapping between objects and the database. However in pract
by acd 7y ago
Will tend to agree with the author.
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/Database_normalization
https://en.wikipedia.org/wiki/Third_normal_form https://en.wikipedia.org/wiki/Third_normal_form
- Daishiman 7y agoThis 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.
- pknopf 7y agoTake a look at these issues: https://github.com/aspnet/EntityFrameworkCore/issues https://github.com/aspnet/EntityFrameworkCore/issues 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.
- jtdev 7y ago> 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.
- BoorishBears 7y agoNamedropping ANSI and ISO to back your side in a technical argument, haha, never change HN... or maybe do just a little...