4 ms·
It's a good description of the problems of ORM and their possible resolutions. Personally, I prefer to interact with a relational database via a good query bui
by neilk 9y ago
It's a good description of the problems of ORM and their possible resolutions.
Personally, I prefer to interact with a relational database via a good query builder. The advantage of a query builder is that you inevitably end up with dozens of slightly different queries. With a query builder you can make a query just like another, but with slightly different constraints or joins or whatever you like.
You can then populate objects with said queries when it make sense, and do other non-objecty operations like reporting and search. The entire point of an object system is to reduce coupling, so IDK why people are so eager to tightly couple their programming model to storage.
But about the Vietnam part... really, that's a shocking analogy. The overlong, painfully US-centric military history part could be completely excised. I didn't even understand the title at first. Vietnam is not solely defined by America's failed attempt to ~~napalm it into submission~~ nobly preserve democracy.
- hyperpallium 9y agoThe entire point of relational algebra was also to reduce coupling... let's couple them! Though to be fair, I suspect the relational approach became popular more because it was easier/faster than because it was flexible. ORM popularity then makes sense.
- le-mark 9y agoI agree that the Vietnam war exposition was very odd and out of place for a technical article. Gavin King (creator of hibernate/nhibernate) has always said ORM's are just a tool in a box and encouraged people to use what's appropriate[1]. I often see project teams adopting an ORM and attempting to shoehorn all database access into the ORM framework they've adopted. Needless to say, these teams grow to hate their ORM, with good reason. The way this manifests in applications is often times a frontend client making several calls to the ORM backend for lists of objects, then mixing, matching, swizzling the data to what needs to be displayed to the user when a single call to a well crafted query would save bandwidth, improve application responsiveness, and be easier to debug and maintain. It is relatively easy to draw a clear line between using ORMs for domain model persistence (complex, stateful CRUD) and SQL for relational model interaction (complex, stateless querying). It really comes down to: don't use ORMs for querying and don't use SQL for complex CRUD [1] https://www.reddit.com/r/programming/comments/2cnw8x/what_orms_have_taught_me_just_learn_sql/cjheyec/ https://www.reddit.com/r/programming/comments/2cnw8x/what_or...
- arwhatever 9y agoConvincing a team to choose the best approach based on the situation is the hardest thing to do in the universe. It's got to be an all-or-nothing decision! 99.9% of the teams in the world are out there right now, either cranking out reams of unnecessarily boilerplate CRUD, or else torturing their application and database performance trying to get their ORM to accomplish things for which it is not at all suited.
- WalterGR 9y agoCitations needed.
- arwhatever 9y agoHave worked on 9 teams in the past 5 1/2 years or so, and 0 of them had the wherewithal to choose the optimal data access strategy on a situational basis. So, 100%, not 99.9% :-)
- igkgudtzucf 9y agoI was dating a Vietnamese woman a little while ago. This eventually, inevitably came up. It is extremely difficult to defend a US policy that measures "success" as a body count metric. The Vietnamese people vividly remember this, I don't think it's appropriate to make flip comparisons to a humanitarian catastrophe perpetrated by people the likes of Henry Kissinger in multiple countries, with body counts of millions.
- deleted 9y ago[deleted]