TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

You might not need an ORM

44 pointsby l5870uoo9yover 2 years ago

27 comments

arcturus17over 2 years ago
Ah, the monthly “do you need an ORM&quot; thread.<p>Please organize yourselves in two equal-height piles around “yes” and “no”, and then a third minuscule one around “the hell do I know, it’s your use case and your code”.<p>See you again in a few weeks!
评论 #34519782 未加载
评论 #34519792 未加载
评论 #34519856 未加载
MajimasEyepatchover 2 years ago
I&#x27;ve found that the problem with not using an ORM is that you can end up writing a lot of repetitive CRUD queries. Every model ends up with the same basic read, insert, update, etc. function, but because you&#x27;re writing untested, un-typechecked SQL queries, they still need to be carefully reviewed, tested, etc. You can write some helper functions to abstract over the repetitive parts, but then you start creeping into home-grown ORM territory, which is much worse than using a standard battle-tested ORM. If I&#x27;m using a ORM, I can be pretty confident that the method to read my model using an ID is going to work without fuss.<p>For a small service with just a few basic queries, skipping the ORM and going straight to SQL is pretty nice. And there are situations where you need custom SQL, like complex reports or dashboards. But for typical CRUD in a team setting, I&#x27;ve found that ORMs can be worth the overhead.
评论 #34519678 未加载
评论 #34519827 未加载
评论 #34519567 未加载
评论 #34519400 未加载
评论 #34519759 未加载
vlunkrover 2 years ago
After working with ORMs for a long time, all I really want is a nice API for building queries (that actually supports all underlying database features) and automatic mapping of the results to whatever objects&#x2F;structs and primitives the language supports.<p>Everything else is IMO a bad layer of abstraction that will eventually bite you when you need to get closer to SQL.
评论 #34519849 未加载
评论 #34519551 未加载
评论 #34519655 未加载
评论 #34520703 未加载
评论 #34519653 未加载
评论 #34519793 未加载
评论 #34519664 未加载
danweeover 2 years ago
Post focuses on the &quot;easy&quot; part (building queries), but leaves as an exercise to the reader how to do the M in ORM: so, once I submit my SQL query and get one or more rows: how do I map them into my (potential) complex set of objects? Sure thing, I can do that manually (it&#x27;s easy), but that&#x27;s the whole point of using ORMs: to not to have to do it manually.<p>I also like the idea of using plain SQL and do all the additional manual work myself (that&#x27;s what I do in personal projects); I like the feeling that I&#x27;m in control. But when it comes to professional work, and there&#x27;s a team behind, then handling raw SQL is a recipe for disaster. ORMs bring consistency to the table, ORMs are not the best technical solution, but are the best solution when it comes to working with people.
评论 #34519765 未加载
评论 #34519682 未加载
评论 #34519686 未加载
rubenfiszelover 2 years ago
I find that the best of both worlds is to use something like sqlx for rust [1], which does compile time checking (using postgres explain analyze!) of the queries and macros for static typing, but still let you write the query raw (and can be turned off completely by removing the trailing macro `!` as an escape hatch)<p>We use it extensively for Windmill (e.g: [2]) and couldn&#x27;t be happier.<p>[1]: <a href="https:&#x2F;&#x2F;github.com&#x2F;launchbadge&#x2F;sqlx">https:&#x2F;&#x2F;github.com&#x2F;launchbadge&#x2F;sqlx</a> [2]: <a href="https:&#x2F;&#x2F;github.com&#x2F;windmill-labs&#x2F;windmill&#x2F;blob&#x2F;d60a770eb710ed3234c77e7da794fe3e0dc13ea4&#x2F;backend&#x2F;windmill-api&#x2F;src&#x2F;apps.rs#L318">https:&#x2F;&#x2F;github.com&#x2F;windmill-labs&#x2F;windmill&#x2F;blob&#x2F;d60a770eb710e...</a>
评论 #34519779 未加载
评论 #34519574 未加载
评论 #34519584 未加载
bayesian_horseover 2 years ago
The reasons you want an ORM or query builder: Reuseability and composeability. In Django for example, you can compose querysets and reuse them in Forms, Admin, Templates, wherever. You can also generate Forms and Admin out of nothing but the model class.<p>Most frameworks are way behind Django&#x2F;Django Rest Framework in that regard. I&#x27;m not saying there aren&#x27;t any others doing something similar, NestJs for example. But I&#x27;m not aware on other solutions.
评论 #34519772 未加载
评论 #34519512 未加载
kyberiasover 2 years ago
This is why Language Integrated Query (LINQ) is so powerful in .NET. You never need to learn any ORM specific query language or syntax since you&#x27;ve probably learned to use LINQ with objects already and then you just continue to use it with a database.
评论 #34556771 未加载
评论 #34520016 未加载
评论 #34519356 未加载
thih9over 2 years ago
This feels like an ad. The author created a tool that makes it easy to ditch ORMs. The tool is referenced 10 times in the article, including the article&#x27;s first sentence and the last sentence. The article also includes examples on how to use the tool.<p>I&#x27;d be fine if it was a &quot;show hn&quot; post. But I thought this is an objective article about ORMs and their pros and cons; this is not the case.
评论 #34520041 未加载
Waterluvianover 2 years ago
I’ve done about ten years of multi-hat development without knowing SQL beyond the basics because an ORM fits my use case well: CRUD of a few million records across a dozen tables utilized internally only be a few hundred humans and thousands of robots, the entire backend written and maintained by 5% of one engineer.<p>My lessons are:<p>- you might not need an ORM, but it’s also fine if it’s the right tool. (Though I wonder if it should be inverted: you might not need SQL)<p>- I wish I learned more SQL just to know it better.<p>- don’t early optimize, but do read up on how you do optimizations with your ORM. That way you can identify when to get ahead of performance woes.<p>- set up a profiling system asap. For example, Django Silk.
评论 #34519630 未加载
评论 #34519326 未加载
dagssover 2 years ago
The main problem with ORM is the &quot;object&quot; part. I feel object-oriented programming had its chance and it failed. Both event sourcing and relational models (=&quot;table modelling&quot;) are better models for programming systems.<p>So by using an ORM, you are (at least in the name, and as traditionally done) taking a better programming model (relational models) and mapping it to an inferior one (OOP) -- also getting a ton of leaky abstractions involved too.<p>I wish there were more &quot;ORMs&quot; that were made with the assumption that Object-Oriented Programming is BAD, and started out with assumptions of wanting to program either in an event sourcing model and&#x2F;or a relational model, and see where that would take things.<p>Related:<p>Fred Brooks, The Mythical Man Month (1975): &quot;Show me your flowchart and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won&#x27;t usually need your flowchart; it&#x27;ll be obvious.&quot;<p>Out of the tar pit paper: <a href="https:&#x2F;&#x2F;curtclifton.net&#x2F;papers&#x2F;MoseleyMarks06a.pdf" rel="nofollow">https:&#x2F;&#x2F;curtclifton.net&#x2F;papers&#x2F;MoseleyMarks06a.pdf</a><p>--<p>My take on the software industry today is that OOP failed to produce good and maintainable code, but instead of fixing that, one is adding the idea of micro-services to try to contain the damage done by OOP.<p>If more people moved to event sourcing, functional code and focusing on data over code, there would be much less need for micro-services etc (or, they just become less relevant).
评论 #34519949 未加载
评论 #34519721 未加载
评论 #34519700 未加载
评论 #34519627 未加载
gigatexalover 2 years ago
Cross posted from a discussion on a different post but I thought it was relevant here as well:<p>I mostly do work on the Python side of things and SQLAlchemy is the de facto ORM there. I hate it. It’s heavy. Opinionated. The happy path seems to be doing things in sessions where joins foreign keys and things are evaluated in the app instead of at the DB level (one can define relationships in models for the ORM to understand but not define explicit foreign key relationships at the DB table level, wtf? Thereby doing joins based on common columns…) and yet I can’t fault ORMs for their ability to get you going fast and help you iterate very quickly. I recently had the chance to start a new side project and trying to go the pure SQL route which I love was so slow in terms of productivity. When I could just model the tables via SQLAlchemy I was able to get to the meat of the thing I was making much quicker. What I didn’t like was all the additional cognitive overhead but I gained DB agnostic ways of querying my data and could use say SQLite for testing and then say Postgres for staging or production by just changing a config whereas if I write pure SQL I might get into issues where the dialects are different such that that flexibility is not there. In the end I am very conflicted. Oh, some context I began my professional life as a DBA and my first love was SQL. I like writing queries and optimizing them and knowing exactly what they’re doing etc.
jchwover 2 years ago
Relatedly, I&#x27;d like to recommend people check out sqlc. It&#x27;s a Go project, although it does technically support codegen to other languages.<p><a href="https:&#x2F;&#x2F;sqlc.dev&#x2F;" rel="nofollow">https:&#x2F;&#x2F;sqlc.dev&#x2F;</a><p>With sqlc, you write queries and get fully typed functions you can call. It&#x27;s not completely perfect, but it&#x27;s pretty good.<p>As a concept, I think this is great. In practice, I&#x27;ve only been able to use it for Go projects using PostgreSQL so far. Definitely worth it though.
kasey_junkover 2 years ago
In the olden days we’d distinguish between an ORM and other kinds of data access abstractions.<p>An orm has a specific job, handling the impedance mismatch between oo and relational paradigms. I almost never use an orm because I think it’s almost always better to avoid mapping objects to relational stores.<p>But! I’d almost never get rid of some of the other things data access abstractions can provide (eg security, typed sql, etc).
KingOfCodersover 2 years ago
From my experience ORMs are very good for fast MVPs and getting something done, but then quite some effort to scale (= replace with hand crafted SQL). Also when scaling, transaction problems show up b&#x2F;c you misunderstood the ORM and it was not an issue with 100 users&#x2F;day, but it is now with 10.000 users&#x2F;day.
pirate787over 2 years ago
I&#x27;ve never fully trusted ORMs (building mostly multi-tenant apps where I want to enforce the tenant ID in every table) and the other issue is that my ORM of choice, Doctrine, has abandoned its API which is forcing re-writes of a decade of code. Would have been better with my own abstraction.
friedman23over 2 years ago
I&#x27;m a current ORM user, specifically Prisma. And it&#x27;s nice that it gives me type checking but the CRUD actions and the programmatic interface are not the real reason I use it. I use it as a tool for declarative schema management, handling schema version control and migrations. If someone has a better solution to this that does not involve xml, I&#x27;m all ears. I&#x27;d personally much rather use <a href="https:&#x2F;&#x2F;pgtyped.vercel.app&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pgtyped.vercel.app&#x2F;</a> than prisma.<p>edit: Ok, I actually read the article... He briefly mentions the migration tool. Author: please go into more detail about how you do schema migrations.
qikInNdOutReplyover 2 years ago
<a href="https:&#x2F;&#x2F;blog.codinghorror.com&#x2F;object-relational-mapping-is-the-vietnam-of-computer-science&#x2F;" rel="nofollow">https:&#x2F;&#x2F;blog.codinghorror.com&#x2F;object-relational-mapping-is-t...</a>
评论 #34519577 未加载
calvinmorrisonover 2 years ago
ORMs do not exist because good developers can&#x27;t write SQL, they exist to prevent Jr developers, offshore experts and general buffonery running amuck with security issues, database design and proper techniques.
评论 #34519344 未加载
评论 #34519329 未加载
评论 #34519834 未加载
评论 #34519645 未加载
seveibarover 2 years ago
Kysely[1] and zapatos[2] are excellent solutions for type-safe typescript query builders. It’s hard to go back to the days of spending 20-30% of your time in the object mapping layer.<p>[1] <a href="https:&#x2F;&#x2F;github.com&#x2F;koskimas&#x2F;kysely">https:&#x2F;&#x2F;github.com&#x2F;koskimas&#x2F;kysely</a> [2] <a href="https:&#x2F;&#x2F;github.com&#x2F;jawj&#x2F;zapatos">https:&#x2F;&#x2F;github.com&#x2F;jawj&#x2F;zapatos</a>
rr888over 2 years ago
I&#x27;ve been using Vert.x a lot and one of the great things is just throwing away the whole Spring magic and going back to basics with a sql query and processing the results without an ORM. Basically ignoring all the Java cruft that gives Java its bad reputation. Its so refreshing I love it.
评论 #34519589 未加载
hprotagonistover 2 years ago
I&#x27;ve used <a href="https:&#x2F;&#x2F;pugsql.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;pugsql.org&#x2F;</a> a few times and generally liked the experience for personal code.<p>... and if it goes to hell, it&#x27;s just sqla-core under the hood, so we&#x27;re all good!
drbojingleover 2 years ago
ORM until you don&#x27;t need to, then SQL. IF your green fielding. If you already have the SQL, just work with it. If all you&#x27;re doing is building Crud, though maybe consider Hasura or something that gives you a performant API instead.
Zigurdover 2 years ago
Android bolted views and updates directly to the SQLite database classes. It was an elegant design for an OS meant to run (at first) on 200Mhz small memory configurations. It didn&#x27;t need an ORM and it enabled apps to persist data asap.
sunflowerdeathover 2 years ago
I saw arguments against ORMs a lot of times, but what about the opposite - you might not need raw SQL and ORM might work just fine?
ac130kzover 2 years ago
Yeah, now imagine a system at the scale of Gitlab, it&#x27;s essentially unmanageable without an ORM, which helps a big time figuring out issues, types, migrating schemas, rewriting and so on. Messing with SQL is suitable for manual query optimization or the simplest databases.
Woodiover 2 years ago
Is it some AI ad or just parody ? Can&#x27;t decide...
combatentropyover 2 years ago
If you&#x27;re happy with your ORM (and, ahem, your users are happy with your app&#x27;s speed), then you can disregard this post.<p>An ORM is an abstraction over what already is a huge abstraction, which is SQL. Therefore it would feel to me like driving a bus by remote control, or something like that.<p>SQL isn&#x27;t a procedural language, like C, Fortran, Cobol, Java, JavaScript, Python, Ruby, etc. It is a &quot;query language&quot;, I guess, where you tell it <i>what</i> you want, and it decides <i>how</i> it&#x27;s actually going to find, filter, sort, etc., that data. It&#x27;s also the only game in town. Is there any widespread alternative to SQL, at least for querying tabular data?<p>The problem with it being so abstract doesn&#x27;t rear its head with simple SELECT statements. They all seem to go fast enough. It isn&#x27;t until you&#x27;re joining tables together, or no longer getting data row for row but instead aggregating, summing, averaging, etc. Suddenly sometimes the whole thing can slow to a crawl.<p>Thankfully databases like Postgres let you prepend a command called EXPLAIN to the problematic query, so that you can diagnose the slowness (if you can understand the output of EXPLAIN). But it was a long time before I got good at reading the EXPLAIN output and finding a way to get it to run faster. Even though SQL is so abstract, more just a <i>description</i> of what you want, there is more than one way to write it --- and the difference in speed can be hundreds or thousands of times.<p>I have had the luxury of working mainly with Postgres for 17 years, and toward the end of it I finally feel supremely confident working directly with it, just using the psql command-line client, and hand-typed SQL in text files, to get exactly what I want, and as fast as I want it (which usually is less than a second). Mind you, I don&#x27;t work with Big Data, just a variety of CRUD apps but they often have mindbending reports requirements.<p>It should not have taken me years and years to master SQL (nor should it you). I think the reason is partly distraction, for those of us that are &quot;full-stack developers&quot;, and also that there is so little education about how to master SQL. I mean, the books and posts are out there, but the attention to them from the community at large is small.<p>But SQL is really not harder than the other languages and techniques you know so well. If developers spent as much time on SQL as they do on the ins and outs of React, containerization, CI&#x2F;CD pipelines, or the quirks of their favorite programming language, I think they would find it easier than most of those things. And it pays rich dividends, because SQL is cross-platform, you can carry that knowledge with you from job to job for the rest of your life, and your inefficient database queries are making your app use quadruple the hardware and 10 times the latency than if you truly mastered SQL.
评论 #34556827 未加载