TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Don't use your ORM entities for everything – embrace the SQL

40 点作者 bubblehack3r大约 1 年前

16 条评论

go_prodev大约 1 年前
As someone who always prefers native SQL over ORM queries, I&#x27;ll add a couple of counterpoints.<p>Most IDEs provide intellisense&#x2F;validation of ORM entities, vs treating SQL like a raw string.<p>ORM entities also make refactoring and impact analysis slightly easier.<p>Despite those benefits, I generally find ORMs a pain for anything besides the most basic queries.
评论 #39869681 未加载
mannyv大约 1 年前
I still don&#x27;t understand why people believe that abstracting away something as important as your data store is a good idea. They quickly run into performance problems that are quite difficult to fix.<p>It&#x27;s funny that the same developers that try to avoid vendor lock-in don&#x27;t realize they&#x27;ve locked themselves into an ORM forever.<p>Plus, SQL isn&#x27;t that hard. And as a backend person, you should be able to visualize your data model anyway. A SQL datatbase is just a bunch of planes, for the most part, and the queries are how you intersect them...more or less.
评论 #39866124 未加载
wuliwong大约 1 年前
I think the correct approach is to understand the SQL that your ORM is using. If you can&#x27;t have it create the correct query than roll your own. I think most of the trouble people get in with ORMs is not taking the time to understand the SQL that it creates and using it incorrectly as a result.
评论 #39866112 未加载
lcnPylGDnU4H9OF大约 1 年前
Comments here make me wonder if I&#x27;ve just been spoiled by ActiveRecord. Not that I use it for all queries but 1) it&#x27;s rare that I have to resort to raw SQL and 2) it kindly gets out of the way when I do.
评论 #39866775 未加载
评论 #39870145 未加载
评论 #39871445 未加载
jillesvangurp大约 1 年前
My simple rule for databases is that if you are not actively querying on it, it doesn&#x27;t need to be a separate table or column. Use the YAGNI rule here and you&#x27;ll be better off. The classic example here is persons that have addresses and phone numbers. Most applications have no requirements to query on most of that: street name, postal code, phone number, etc. Less tables and columns mean simpler joins (or better, no joins at all). Any structured data that you don&#x27;t query, just store it in json form in a blob and simplify your schema. Anything that actually requires complex querying, consider using a proper search engine. Or extract it to a dedicated field with some index on it that actually helps you querying effectively. The golden rule here is that if that query is connected to user input you probably need some notion of ranking, fuzzy searches, etc.<p>Either way, everything gets easier with a simple schema. Faster query and insert performance, easier to reason about when doing transactions, easier to maintain, etc.
评论 #39867192 未加载
moritonal大约 1 年前
Whilst true from a performance level, do appreciate there is a complexity cost with raw SQL given how it allows for inconsistent ways of working.<p>Coming from a Rails legacy app, these raw SQL &quot;clever ideas&quot; are where I found the most issues.
ta2234234242大约 1 年前
In the 1980&#x27;s we had C&#x2F;C++&#x2F;Ada&#x2F;Pascal&#x2F;Fortran&#x2F;Assembly&#x2F;Lisp. Since the 1980&#x27;s the languages have exploded.<p>But we still only have one language for querying a database. And a kinda not very good one at that. Why is that?<p><a href="https:&#x2F;&#x2F;www.holistics.io&#x2F;blog&#x2F;quel-vs-sql&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.holistics.io&#x2F;blog&#x2F;quel-vs-sql&#x2F;</a><p>One could argue that ORM&#x27;s are the alternative language people are looking for.
评论 #39867300 未加载
评论 #39868338 未加载
moribvndvs大约 1 年前
I always admired micro ORMs like Dapper. The hard (or at least time wasting or error prone) tasks are:<p>- mapping results to app entities or projections<p>- input sanitization<p>- dynamic query building<p>- connection pooling and transaction management<p>- supporting multiple SQL dialects with one code base<p>After many years of experience with Hibernate, NHibernate, Entity Framework, and a plethora of other full ORMs, I absolutely do not want lazy&#x2F;eager loading, opaque query DSLs and criteria APIs, and dealing with leaky abstractions for queryables (looking at you, LINQ and JPA), and I’m pretty wary anymore over cascading persistence. These things all look great in tutorials and are nearly magical in your PoC or simple projects, but in my experience, performance problems, unexpected and sometimes hard to diagnose bugs, and lots of ugly yak shaving are inevitable for moderate complexity apps over time.<p>Of all of them, I enjoyed JOOQ’s SQL builder with or without codegen the most if I need to support multiple dialects or complex dynamic queries.<p>Speaking of JOOQ, anyone have recommendations for something similar on nodejs? I haven’t been particularly excited by prisma, typeorm, or sequelize.
评论 #39868112 未加载
Spivak大约 1 年前
&gt; Will you actually need to change between fundamentally different database technologies?<p>Yes, use sqlite locally for development and run PG in prod. Unit tests can now use the db and finish in milliseconds. You get unit tests that have the power of integration tests and don&#x27;t have to ever stub out your db. I use Redislite for the same thing.<p>I&#x27;m of the opinion that SQLite is the musl of the SQL world. By deciding that you&#x27;ll support it first-class you&#x27;ll avoid the sharp edges of database specific behavior and extension hell and write better more maintainable code.<p>&quot;Sorry we can&#x27;t actually put that logic the database, SQLite doesn&#x27;t support spooky action at a distance.&quot;
评论 #39872758 未加载
评论 #39869235 未加载
Zambyte大约 1 年前
The article mentions database portability as an advantage of ORMs, and I agree - to me that is basically the only real advantage to ORMs. The article also mentions that database portability is not a very compelling advantage, since lots of applications don&#x27;t actually need that, which I also agree with.<p>Personally I just pick either PostgreSQL or SQLite depending on my use case (and they&#x27;re different enough that there is always one obvious choice) and just interface with them directly. Hasn&#x27;t served me wrong yet.
评论 #39866129 未加载
nimish大约 1 年前
The times I&#x27;ve run into people who&#x27;ve written a library to handle something built into Postgres... everyone likes to reinvent timestamp and range handling for some reason.
karmakaze大约 1 年前
You can learn a lot about a system merely by looking at the database schema and data transformations to new consistent data. How exactly these processes do what they do is an implementation detail. <i>Think in invariants</i>, not <i>mental simulation</i> of incidentally complex procedures. In this light knowing SQL is a superpower that applies to all systems built with any RDBMS.
apwell23大约 1 年前
This has to be one of the long lasting topics on HN. I remember commenting on &quot;vietnam of cs&quot; blogpost like two decades ago.
ckmar大约 1 年前
Have you seen Pure ORM? It&#x27;s an ORM that <i>purely</i> does object relational mapping.<p>You write SQL but instead of getting back flat and potentially-collided data, you get back pure objects which are properly structured.<p><a href="https:&#x2F;&#x2F;github.com&#x2F;craigmichaelmartin&#x2F;pure-orm">https:&#x2F;&#x2F;github.com&#x2F;craigmichaelmartin&#x2F;pure-orm</a>
deepsun大约 1 年前
JOOQ is awesome, doesn&#x27;t try to do too much. Also tried to use Exposed from Kotlin, but it&#x27;s way too young, support only simple data types.
gigatexal大约 1 年前
Couldn’t agree more. There’s huge benefits to ORMs but when the fast path is needed hand written and optimized SQL is my go to.