编程与软件工程wozniak.ca
ORM 教会我的事：还是直接学 SQL 吧
What ORMs have taught me: just learn SQL (2014)
2014 — 2016，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇 2014 年的文章从使用 ORM 的经验出发，标题给出的结论是“干脆学 SQL”：开发者应理解 SQL，而不是把数据库操作完全交给 ORM 抽象。文章隔多年仍被讨论，评论多把它延伸为更务实的判断：ORM 适合简单 CRUD，复杂查询和数据库特性往往要手写 SQL，两者可混合使用。
为什么经久不衰：因为它抓住了 ORM 与 SQL 的长期争论，而评论区的混合使用共识比单纯站队更有工程参考价值。
HN 评论精选
ORM 不是免学 SQL，现代 ORM 可回退原生 SQL，手写替代往往更糟。
十年前，每隔一周就有博客文章哀叹 ORM，那些文章往往有道理。到 2016 年，这种情绪已经过时。如果你以为用 ORM 就不用学 SQL，你会很痛苦；多数差评来自没真正学过 SQL 或所选 ORM 的人。ORM 在应用层提供类型检查，通常性能更好，但你仍必须理解关系数据库基础。如果不用 ORM，你最终会自己写一个，而且比专门做这个的人写得差得多。十年前抱怨 ORM 让自定义或复杂 SQL 无法实现、与存储过程配合不好还有效，但今天主流 ORM 大多能方便地退回自定义 SQL。
StevePerkins查看英文原文
Ten years ago, there was a blog post every other week bemoaning ORM's. Ten years ago, those posts often had merit. In 2016, this sentiment is outdated. A few points: 1. If you think that using an ORM means you don't have to learn SQL, then you're going to have a bad time. This is where most of the bad press originates... from people who never really learned SQL or their chosen ORM. An ORM provides type checking at your application layer, and typically better performance (unless you plan on hand-rolling your own multi-level cache system). But you still must understand relational database fundamentals. 2. If you're not using an ORM, then you ultimately end up writing one. And doing a far worse job than the people who focus on that for a living. It's no different from people who "don't need a web framework", and then go on to re-implement half of Rails or Spring (without accounting for any CSRF protection). Learning any framework at a professional level is a serious time investment, and many student beginners or quasi-professional cowboys don't want to do that. So they act like their hand-rolled crap is a badge of honor. 3. Ten years ago, it was a valid complaint that ORM's made custom or complex SQL impossible, didn't play well with stored procedures, etc. But it's 2016 now, and this is as obsolete as criticizing Java by pointing to the EJB 2.x spec. I can't think of a single major ORM framework today that doesn't make it easy to drop down to custom SQL when necessary.
ORM 适合简单 CRUD，复杂查询应手写 SQL。
我喜欢说“ORM 让简单的事更容易，让困难的事更困难”。简单 CRUD 用 ORM 容易得多；需要多个 join 的复杂查询，最好自己写。我倾向于用 ORM 或数据库抽象工具做插入、更新、删除，但大多数 SELECT 自己写，只取所需字段，必要时手动映射到对象。
Gustek查看英文原文
I like to say "ORMs make easy thing easier and hard things harder". What i mean by that is, any simple CRUD operations are much easier in ORM. The hard things, i mean any complex queries that need more than one join you are probably better of writing yourself. In the end i prefer to do inserts, updates and deletes with ORM (or some other database abstraction tools) but most SELECTs i write myself, fetching exactly what i need and mapping result to objects if needed manually.
ORM 在简单持久化上便利且有类型检查，但复杂数据库特性会逼你放弃它。
我写了很多年原生 SQL，2005 年左右转向 ORM，为了支持不同数据库、有好的模型等。坦白说，直接设置对象字段再 save，比写 update 语句方便很多；类型检查能在数据库于大事务中途报错前发现拼写错误，强类型语言如 Scala 的 Slick 更好。但缺点是：只有当你需要的东西是数据库特性的最小公分母时，ORM 才好用。我现在的 Clojure + Postgres 项目用到 HStore、JSON、子查询套子查询、upsert、函数等，ORM 不适合；我试过简单的 Korma，最后因为难以正确执行复杂查询而放弃。
terhechte查看英文原文
I used to write raw SQL for many years, then, around 2005 switched over to ORMs in order to be able to target different databases, have a nice model, etc. Lets be honest here, the ease of justing doing: p.username = "Carl" p.age = 33 p.save instead of "update users set username=:username, age=:age where id=:id" has a ton of advantages. For one, some sort of syntax or type checker is actually trying to understand your queries and makes it easy to find typos before the database laments in the middle of a huge transaction. Strongly typed languages are even cooler here (most notably Slick for Scala, which has a fully type-checked DSL for database querying which makes it really difficult to create typos) [1]. However, the downside of this is that it only works as long as whatever you need from your database is the lowest common denominator of database features. I'm currently working on a Clojure + Postgres project and I'm using all the bells & whistles that Postgres has to offer: HStore types, Json Types, subqueries in subqueries, Upserts, functions, etc. I have a rather complex database that I'm running analytical queries against, and using an ORM for this would simply not work. I'd spend half my time trying to figure out how to implement a certain Postgres feature in -insert-or-name-here. I actually started with Korma [2], a simple Clojure ORM, and gave up because it was too tedious trying to figure out how to get it to correctly run my 4-function column result query. I've since switched to YeSQL [3] which follows a very interesting idea: You write queries in .sql files (full editor support, jay) and tag every query with a name. YeSQL then reads these .sql files during compile time and dynamically generates clojure functions with the correct amount of parameters based on these queries. It is kinda the best of both worlds. Example: queries.sql: -- name: get-users -- a function to retrieve the user by name select * from users where username=:name clojure.clj: (defqueries "some/where/queries.sql") ;; now I can do: (get-users "carl") I think it really depends on the use case. If the database model is simple and there're no crazy database technologies in use, I'd rather go and use an ORM again I guess. [1] http://slick.typesafe.com/ [2] http://sqlkorma.com/ [3] https://github.com/krisajenkins/yesql
应按用途分工：ORM 管有状态 CRUD，SQL 管复杂查询。
有趣的是，从来没人听 Hibernate 创建者 Gavin King 的话：你不该用 ORM 做所有事。可以较容易地划清界线：用 ORM 做领域模型持久化，也就是复杂、有状态的 CRUD；用 SQL 做关系模型交互，也就是复杂、无状态的查询。底线是：不要用 ORM 做查询，不要用 SQL 做复杂 CRUD。
lukaseder查看英文原文
Interestingly enough, no one ever listened to Gavin King (creator of Hibernate), when he said that you shouldn't use an ORM for everything. It is relatively easy to draw a clear line between using: * ORMs for domain model persistence (complex, stateful CRUD) * SQL for relational model interaction (complex, stateless querying) Bottom line: * Don't use ORMs for querying * Don't use SQL for complex CRUD
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选