ORM 的价值与边界超越信仰之争的工程决策指南开篇一场永不停歇的圣战如果你在一个技术团队待得足够久你一定见过这样的场景——代码评审会上一位同事指着屏幕说这段查询为什么不用 ORM手写 SQL 太难维护了。另一位同事立刻反驳“ORM 生成的 SQL 惨不忍睹性能差得要命真正懂数据库的人都手写 SQL。”空气突然凝固。两方各执一词谁也说服不了谁。这不是技术讨论这是信仰之争。我写了十几年 Python经历过从 SQLAlchemy 到 Django ORM从 Peewee 到 Tortoise ORM 的各种项目。我的结论是ORM 和手写 SQL 不是对立关系而是工具箱里不同尺寸的扳手。真正的高级工程师不会在全用或全不用之间做选择而是懂得在什么场景下用什么工具。这篇文章我想系统地拆解 ORM 的价值、边界和决策框架帮助你在团队中终结这场无意义的争论。一、ORM 到底解决了什么问题在讨论边界之前先诚实地承认 ORM 带来的价值。1.1 消除阻抗失配Impedance Mismatch面向对象的世界和关系型数据库的世界天生存在阻抗失配——对象有继承、多态、引用关系表有外键、范式、连接。ORM 的核心价值就是桥接这两个世界。# 没有 ORM 时你需要手动映射importpymysqldefget_user_with_orders(user_id):connpymysql.connect(...)cursorconn.cursor(pymysql.cursors.DictCursor)cursor.execute(SELECT * FROM users WHERE id %s,(user_id,))user_rowcursor.fetchone()cursor.execute(SELECT * FROM orders WHERE user_id %s,(user_id,))order_rowscursor.fetchall()# 手动组装对象userUser(**user_row)user.orders[Order(**row)forrowinorder_rows]cursor.close()conn.close()returnuser# 使用 SQLAlchemy ORMdefget_user_with_orders(user_id):returnsession.query(User).options(joinedload(User.orders)).get(user_id)差距显而易见。ORM 不仅减少了代码量更重要的是将数据访问逻辑内聚到模型定义中让业务代码专注于业务本身。1.2 数据库无关性# Django ORM 模型定义可在 PostgreSQL、MySQL、SQLite 间无缝切换classArticle(models.Model):titlemodels.CharField(max_length200)contentmodels.TextField()created_atmodels.DateTimeField(auto_now_addTrue)authormodels.ForeignKey(User,on_deletemodels.CASCADE)tagsmodels.ManyToManyField(Tag)classMeta:indexes[models.Index(fields[created_at]),models.Index(fields[author,-created_at]),]开发用 SQLite测试用 PostgreSQL生产用 MySQL——ORM 让这种切换几乎零成本。虽然现实中很少真的切数据库但本地开发与生产环境的差异化配置确实是刚需。1.3 安全性天然防 SQL 注入# 危险字符串拼接queryfSELECT * FROM users WHERE name {user_input}# 安全参数化查询手写 SQL 也能做到但需要纪律cursor.execute(SELECT * FROM users WHERE name %s,(user_input,))# ORM天然安全你根本不接触 SQL 字符串User.objects.filter(nameuser_input)1.4 迁移管理Migration这是很多人忽视的巨大价值。Django 的makemigrationsmigrateAlembic 的版本化迁移让数据库 Schema 变更变得可追踪、可回滚、可协作。# Django 迁移工作流python manage.py makemigrations# 自动检测模型变更生成迁移文件python manage.py migrate# 应用迁移python manage.py migrate app_name 0003# 回滚到特定版本没有 ORM 的迁移系统团队只能依赖手写 SQL 脚本 人工管理执行顺序这在多人协作中是灾难。1.5 代码即文档classOrder(models.Model):订单模型 —— 看这个类定义就能理解数据结构usermodels.ForeignKey(User,on_deletemodels.CASCADE,related_nameorders)statusmodels.CharField(max_length20,choicesSTATUS_CHOICES,defaultpending)total_amountmodels.DecimalField(max_digits10,decimal_places2)created_atmodels.DateTimeField(auto_now_addTrue)paid_atmodels.DateTimeField(nullTrue,blankTrue)新成员加入团队看模型定义就能理解 80% 的业务数据结构。这是手写 SQL 散落在各处的项目无法做到的。二、ORM 的边界在哪里承认价值之后也要诚实面对 ORM 力不从心的场景。2.1 复杂查询的表达力瓶颈-- 一条典型的分析查询用户最近30天的消费排名带窗口函数SELECTuser_id,username,total_spent,RANK()OVER(ORDERBYtotal_spentDESC)asspending_rank,total_spent/SUM(total_spent)OVER()*100aspercentageFROM(SELECTu.idasuser_id,u.username,COALESCE(SUM(o.amount),0)astotal_spentFROMusers uLEFTJOINorders oONu.ido.user_idANDo.created_atNOW()-INTERVAL30 daysANDo.statuscompletedGROUPBYu.id,u.username)subqueryWHEREtotal_spent0ORDERBYspending_rank;用 Django ORM 写这个可以但代码会变成这样fromdjango.db.modelsimportSum,F,Window,Valuefromdjango.db.models.functionsimportRank,Coalesce# 勉强能写但可读性已经不如直接看 SQLsubquery(User.objects.filter(orders__statuscompleted,orders__created_at__gtethirty_days_ago).annotate(total_spentCoalesce(Sum(orders__amount),Value(0))).filter(total_spent__gt0).annotate(spending_rankWindow(expressionRank(),order_byF(total_spent).desc())))当 ORM 代码比等价 SQL 更难读时ORM 就失去了存在意义。2.2 性能不可控的 N1 问题# 经典 N1 问题 —— 看起来无害实际执行了 101 条 SQLarticlesArticle.objects.all()[:100]forarticleinarticles:print(article.author.name)# 每次循环触发一次查询# 正确做法预加载articlesArticle.objects.select_related(author).all()[:100]ORM 的便利性恰恰是它的陷阱——它让低效查询看起来和高效查询一样自然缺乏经验的开发者很难察觉性能问题。2.3 批量操作的效率鸿沟# ORM 方式逐条更新假设10万条数据foruserinUser.objects.filter(is_activeTrue):user.last_notifiednow()user.save()# 10万次 UPDATE 语句# 正确的 ORM 方式User.objects.filter(is_activeTrue).update(last_notifiednow())# 但如果更新逻辑复杂每行的值不同ORM 就力不从心了# 手写 SQL 可以用 CASE WHEN 或临时表批量处理-- 手写 SQL一条语句完成差异化批量更新UPDATEusersSETlevelCASEWHENtotal_points10000THENgoldWHENtotal_points5000THENsilverELSEbronzeENDWHEREis_activeTRUE;2.4 数据库特有功能PostgreSQL 的 JSONB 操作、全文搜索、递归 CTE、物化视图MySQL 的空间索引、特定的锁机制——这些数据库专属能力ORM 要么不支持要么支持得很别扭。# Django 对 PostgreSQL JSONB 有不错的支持但仍有边界fromdjango.contrib.postgres.fieldsimportJSONFieldfromdjango.db.modelsimportF# 这个可以Product.objects.filter(metadata__brandApple)# 但复杂的 JSONB 操作如 jsonb_array_elements就需要 raw SQLProduct.objects.raw( SELECT p.*, elem-color as color FROM products p, jsonb_array_elements(p.metadata-variants) elem WHERE elem-stock 0 )三、决策框架什么时候用什么与其争论全用或全不用不如建立清晰的决策标准。3.1 分层策略推荐方案┌─────────────────────────────────────────────────┐ │ 应用代码层 │ ├─────────────────────────────────────────────────┤ │ 简单 CRUD │ 复杂查询/报表 │ 批量/ETL │ │ ────────── │ ────────── │ ──────── │ │ ✅ ORM │ ✅ Raw SQL │ ✅ Raw SQL │ │ 模型方法/Manager │ 封装到 Repository│ 独立脚本 │ ├─────────────────────────────────────────────────┤ │ 数据访问层Repository / DAO │ ├─────────────────────────────────────────────────┤ │ 数据库 │ └─────────────────────────────────────────────────┘3.2 具体决策矩阵场景推荐方案理由单表 CRUDORM简洁安全变更友好简单关联查询1-2层ORM select_related可读性好性能可控复杂报表/分析Raw SQL表达力强性能可优化批量数据处理Raw SQL / COPY效率差距可达百倍数据库迁移ORM Migration版本管理不可替代全文搜索/地理查询Raw SQL 数据库扩展ORM 支持有限跨库/跨服务查询Raw SQLORM 模型边界不适用3.3 代码架构让两者共存关键设计原则将 Raw SQL 封装在 Repository 层不让它泄漏到业务逻辑中。# repository/user_repository.pyfromdjango.dbimportconnectionfrom.modelsimportUserclassUserRepository:用户数据访问层 —— ORM 和 Raw SQL 在此共存# ORM 方法处理简单 CRUD staticmethoddefget_by_id(user_id:int)-User:returnUser.objects.select_related(profile).get(iduser_id)staticmethoddefcreate_user(username:str,email:str,**kwargs)-User:returnUser.objects.create(usernameusername,emailemail,**kwargs)staticmethoddefget_active_users():returnUser.objects.filter(is_activeTrue).select_related(profile)# Raw SQL 方法处理复杂查询 staticmethoddefget_user_spending_report(days:int30)-list[dict]:用户消费报表 —— 复杂聚合查询手写 SQL 更清晰高效query WITH user_spending AS ( SELECT u.id, u.username, u.email, COALESCE(SUM(o.amount), 0) as total_spent, COUNT(o.id) as order_count, MAX(o.created_at) as last_order_date FROM users u LEFT JOIN orders o ON u.id o.user_id AND o.created_at NOW() - INTERVAL %s days AND o.status completed GROUP BY u.id, u.username, u.email ) SELECT *, RANK() OVER (ORDER BY total_spent DESC) as rank, NTILE(10) OVER (ORDER BY total_spent DESC) as decile FROM user_spending WHERE total_spent 0 ORDER BY total_spent DESC; withconnection.cursor()ascursor:cursor.execute(query,[days])columns[col[0]forcolincursor.description]return[dict(zip(columns,row))forrowincursor.fetchall()]staticmethoddefbulk_update_user_levels():批量更新用户等级 —— 单条 SQL 比循环快 100 倍query UPDATE users SET level CASE WHEN total_points 10000 THEN gold WHEN total_points 5000 THEN silver WHEN total_points 1000 THEN bronze ELSE basic END, level_updated_at NOW() WHERE is_active TRUE; withconnection.cursor()ascursor:cursor.execute(query)returncursor.rowcount# services/user_service.py —— 业务层完全不知道底层是 ORM 还是 Raw SQLfromrepository.user_repositoryimportUserRepositoryclassUserService:def__init__(self):self.repoUserRepository()defget_monthly_report(self):业务逻辑只关心获取数据不关心是 ORM 还是 SQLreport_dataself.repo.get_user_spending_report(days30)# 业务处理...returnself._format_report(report_data)defregister_user(self,username,email,password):简单 CRUD 背后用的是 ORM调用方无感知userself.repo.create_user(usernameusername,emailemail)# 后续业务逻辑...returnuser四、如何终结团队的信仰之争4.1 用数据说话而非用观点当有人说ORM 性能差时不要争论直接测量# 建立性能基准测试importtimeimportdjangofromdjango.dbimportconnection,reset_queries django.setup()settings.DEBUGTrue# 开启查询日志defbenchmark_orm():测量 ORM 查询reset_queries()starttime.perf_counter()# ORM 查询userslist(User.objects.filter(is_activeTrue).select_related(profile).prefetch_related(orders).annotate(order_countCount(orders))[:1000])elapsedtime.perf_counter()-start query_countlen(connection.queries)print(fORM:{elapsed:.4f}s,{query_count}queries)returnusersdefbenchmark_raw_sql():测量等价的 Raw SQLstarttime.perf_counter()withconnection.cursor()ascursor:cursor.execute( SELECT u.*, p.*, COUNT(o.id) as order_count FROM users u LEFT JOIN profiles p ON u.id p.user_id LEFT JOIN orders o ON u.id o.user_id WHERE u.is_active TRUE GROUP BY u.id, p.id LIMIT 1000 )resultscursor.fetchall()elapsedtime.perf_counter()-startprint(fRaw SQL:{elapsed:.4f}s, 1 query)returnresults# 运行对比benchmark_orm()benchmark_raw_sql()大多数情况下正确使用 ORM加了 select_related/prefetch_related的性能与手写 SQL 差距在 10%-30% 之内这对大部分 CRUD 场景完全可以接受。而在复杂分析查询中差距可能是 5-10 倍——这时候就该切换手段。4.2 建立团队规范而非教条# 团队数据访问规范 v1.0 ## 原则 - ORM 是默认选择Raw SQL 是补充手段 - 两者通过 Repository 层统一封装 - 任何 Raw SQL 必须有注释说明为什么不用 ORM ## 必须用 ORM 的场景 - 所有表结构定义和迁移 - 单表/简单关联的 CRUD 操作 - 需要跨数据库兼容的查询 ## 允许用 Raw SQL 的场景 - 涉及窗口函数、递归CTE、复杂子查询 - 批量数据处理1万条 - 性能基准测试证明 ORM 方案慢 3 倍以上 - 使用数据库特有功能全文搜索、JSONB 深度操作等 ## 代码审查要点 - [ ] ORM 查询是否有 N1 问题 - [ ] Raw SQL 是否使用参数化防注入 - [ ] Raw SQL 是否封装在 Repository 层 - [ ] 是否有对应的测试覆盖4.3 高级工程师的思维方式真正的高级工程师不会说我信 ORM或我信 SQL他们的思考路径是1. 这个需求的数据访问模式是什么 ├── 简单 CRUD → ORM开发效率优先 ├── 复杂分析 → Raw SQL表达力优先 └── 高并发热点 → 可能需要缓存/读写分离架构优先 2. 可维护性影响多大 ├── 这段代码未来谁会改 ├── 团队的 SQL 水平如何 └── 是否容易写出测试 3. 性能是否是当前瓶颈 ├── 先测量后优化 ├── 80% 的性能问题出在缺少索引而非 ORM 开销 └── 过早优化是万恶之源五、一个真实案例电商订单系统的混合实践# models.py —— ORM 定义数据结构和关系classOrder(models.Model):usermodels.ForeignKey(User,on_deletemodels.PROTECT,related_nameorders)statusmodels.CharField(max_length20,db_indexTrue)total_amountmodels.DecimalField(max_digits10,decimal_places2)created_atmodels.DateTimeField(auto_now_addTrue,db_indexTrue)classMeta:indexes[models.Index(fields[user,-created_at]),models.Index(fields[status,created_at]),]classOrderItem(models.Model):ordermodels.ForeignKey(Order,on_deletemodels.CASCADE,related_nameitems)productmodels.ForeignKey(Product,on_deletemodels.PROTECT)quantitymodels.PositiveIntegerField()unit_pricemodels.DecimalField(max_digits10,decimal_places2)# repository/order_repository.pyclassOrderRepository:# ORM创建订单事务性操作ORM 更安全staticmethodtransaction.atomicdefcreate_order(user,cart_items:list[dict])-Order:totalsum(item[price]*item[quantity]foritemincart_items)orderOrder.objects.create(useruser,total_amounttotal,statuspending)order_items[OrderItem(orderorder,product_iditem[product_id],quantityitem[quantity],unit_priceitem[price])foritemincart_items]OrderItem.objects.bulk_create(order_items)# 批量插入returnorder# ORM查询用户最近订单简单关联staticmethoddefget_user_recent_orders(user_id:int,limit:int20):return(Order.objects.filter(user_iduser_id).select_related(user).prefetch_related(items__product).order_by(-created_at)[:limit])# Raw SQL运营日报复杂聚合 窗口函数staticmethoddefget_daily_sales_report(start_date,end_date)-list[dict]:query WITH daily_sales AS ( SELECT DATE(created_at) as sale_date, COUNT(*) as order_count, SUM(total_amount) as revenue, COUNT(DISTINCT user_id) as unique_buyers, AVG(total_amount) as avg_order_value FROM orders WHERE status completed AND created_at BETWEEN %s AND %s GROUP BY DATE(created_at) ) SELECT *, revenue - LAG(revenue) OVER (ORDER BY sale_date) as revenue_change, ROUND( (revenue - LAG(revenue) OVER (ORDER BY sale_date)) / NULLIF(LAG(revenue) OVER (ORDER BY sale_date), 0) * 100, 2) as growth_rate FROM daily_sales ORDER BY sale_date; withconnection.cursor()ascursor:cursor.execute(query,[start_date,end_date])columns[col[0]forcolincursor.description]return[dict(zip(columns,row))forrowincursor.fetchall()]# Raw SQL库存扣减需要 SELECT FOR UPDATE 精确控制锁staticmethodtransaction.atomicdefdeduct_stock(product_id:int,quantity:int)-bool:withconnection.cursor()ascursor:cursor.execute( UPDATE products SET stock stock - %s WHERE id %s AND stock %s ,[quantity,product_id,quantity])returncursor.rowcount0六、总结务实主义胜过教条主义维度ORM 擅长Raw SQL 擅长开发效率✅ CRUD 快速开发❌ 需要更多代码可维护性✅ 模型即文档⚠️ 需要良好注释查询表达力⚠️ 简单查询优秀✅ 无上限性能控制⚠️ 需要经验避坑✅ 完全可控安全性✅ 天然防注入⚠️ 需要纪律迁移管理✅ 版本化管理❌ 需额外工具最终建议ORM 是默认选择它解决 80% 的场景且降低团队认知负担。Raw SQL 是精确工具在 ORM 力不从心时果断切换。用 Repository 模式隔离让业务层不关心底层实现。用性能数据决策而非个人偏好。写进团队规范让决策有据可依而非每次代码评审都争论。记住——工具没有信仰只有适用场景。能在两种方案间自如切换才是高级工程师的标志。互动话题你的团队是如何处理 ORM 与 Raw SQL 的边界问题的有没有遇到过 ORM 性能踩坑的经历欢迎在评论区分享你的实战经验。参考资料SQLAlchemy 官方文档Django ORM 查询优化指南《Architecture Patterns with Python》— Harry Percival Bob Gregory《High Performance MySQL》— Baron Schwartz et al.Martin Fowler - ORM Hate
ORM 的价值与边界：超越信仰之争的工程决策指南
发布时间：2026/5/19 11:40:50
ORM 的价值与边界超越信仰之争的工程决策指南开篇一场永不停歇的圣战如果你在一个技术团队待得足够久你一定见过这样的场景——代码评审会上一位同事指着屏幕说这段查询为什么不用 ORM手写 SQL 太难维护了。另一位同事立刻反驳“ORM 生成的 SQL 惨不忍睹性能差得要命真正懂数据库的人都手写 SQL。”空气突然凝固。两方各执一词谁也说服不了谁。这不是技术讨论这是信仰之争。我写了十几年 Python经历过从 SQLAlchemy 到 Django ORM从 Peewee 到 Tortoise ORM 的各种项目。我的结论是ORM 和手写 SQL 不是对立关系而是工具箱里不同尺寸的扳手。真正的高级工程师不会在全用或全不用之间做选择而是懂得在什么场景下用什么工具。这篇文章我想系统地拆解 ORM 的价值、边界和决策框架帮助你在团队中终结这场无意义的争论。一、ORM 到底解决了什么问题在讨论边界之前先诚实地承认 ORM 带来的价值。1.1 消除阻抗失配Impedance Mismatch面向对象的世界和关系型数据库的世界天生存在阻抗失配——对象有继承、多态、引用关系表有外键、范式、连接。ORM 的核心价值就是桥接这两个世界。# 没有 ORM 时你需要手动映射importpymysqldefget_user_with_orders(user_id):connpymysql.connect(...)cursorconn.cursor(pymysql.cursors.DictCursor)cursor.execute(SELECT * FROM users WHERE id %s,(user_id,))user_rowcursor.fetchone()cursor.execute(SELECT * FROM orders WHERE user_id %s,(user_id,))order_rowscursor.fetchall()# 手动组装对象userUser(**user_row)user.orders[Order(**row)forrowinorder_rows]cursor.close()conn.close()returnuser# 使用 SQLAlchemy ORMdefget_user_with_orders(user_id):returnsession.query(User).options(joinedload(User.orders)).get(user_id)差距显而易见。ORM 不仅减少了代码量更重要的是将数据访问逻辑内聚到模型定义中让业务代码专注于业务本身。1.2 数据库无关性# Django ORM 模型定义可在 PostgreSQL、MySQL、SQLite 间无缝切换classArticle(models.Model):titlemodels.CharField(max_length200)contentmodels.TextField()created_atmodels.DateTimeField(auto_now_addTrue)authormodels.ForeignKey(User,on_deletemodels.CASCADE)tagsmodels.ManyToManyField(Tag)classMeta:indexes[models.Index(fields[created_at]),models.Index(fields[author,-created_at]),]开发用 SQLite测试用 PostgreSQL生产用 MySQL——ORM 让这种切换几乎零成本。虽然现实中很少真的切数据库但本地开发与生产环境的差异化配置确实是刚需。1.3 安全性天然防 SQL 注入# 危险字符串拼接queryfSELECT * FROM users WHERE name {user_input}# 安全参数化查询手写 SQL 也能做到但需要纪律cursor.execute(SELECT * FROM users WHERE name %s,(user_input,))# ORM天然安全你根本不接触 SQL 字符串User.objects.filter(nameuser_input)1.4 迁移管理Migration这是很多人忽视的巨大价值。Django 的makemigrationsmigrateAlembic 的版本化迁移让数据库 Schema 变更变得可追踪、可回滚、可协作。# Django 迁移工作流python manage.py makemigrations# 自动检测模型变更生成迁移文件python manage.py migrate# 应用迁移python manage.py migrate app_name 0003# 回滚到特定版本没有 ORM 的迁移系统团队只能依赖手写 SQL 脚本 人工管理执行顺序这在多人协作中是灾难。1.5 代码即文档classOrder(models.Model):订单模型 —— 看这个类定义就能理解数据结构usermodels.ForeignKey(User,on_deletemodels.CASCADE,related_nameorders)statusmodels.CharField(max_length20,choicesSTATUS_CHOICES,defaultpending)total_amountmodels.DecimalField(max_digits10,decimal_places2)created_atmodels.DateTimeField(auto_now_addTrue)paid_atmodels.DateTimeField(nullTrue,blankTrue)新成员加入团队看模型定义就能理解 80% 的业务数据结构。这是手写 SQL 散落在各处的项目无法做到的。二、ORM 的边界在哪里承认价值之后也要诚实面对 ORM 力不从心的场景。2.1 复杂查询的表达力瓶颈-- 一条典型的分析查询用户最近30天的消费排名带窗口函数SELECTuser_id,username,total_spent,RANK()OVER(ORDERBYtotal_spentDESC)asspending_rank,total_spent/SUM(total_spent)OVER()*100aspercentageFROM(SELECTu.idasuser_id,u.username,COALESCE(SUM(o.amount),0)astotal_spentFROMusers uLEFTJOINorders oONu.ido.user_idANDo.created_atNOW()-INTERVAL30 daysANDo.statuscompletedGROUPBYu.id,u.username)subqueryWHEREtotal_spent0ORDERBYspending_rank;用 Django ORM 写这个可以但代码会变成这样fromdjango.db.modelsimportSum,F,Window,Valuefromdjango.db.models.functionsimportRank,Coalesce# 勉强能写但可读性已经不如直接看 SQLsubquery(User.objects.filter(orders__statuscompleted,orders__created_at__gtethirty_days_ago).annotate(total_spentCoalesce(Sum(orders__amount),Value(0))).filter(total_spent__gt0).annotate(spending_rankWindow(expressionRank(),order_byF(total_spent).desc())))当 ORM 代码比等价 SQL 更难读时ORM 就失去了存在意义。2.2 性能不可控的 N1 问题# 经典 N1 问题 —— 看起来无害实际执行了 101 条 SQLarticlesArticle.objects.all()[:100]forarticleinarticles:print(article.author.name)# 每次循环触发一次查询# 正确做法预加载articlesArticle.objects.select_related(author).all()[:100]ORM 的便利性恰恰是它的陷阱——它让低效查询看起来和高效查询一样自然缺乏经验的开发者很难察觉性能问题。2.3 批量操作的效率鸿沟# ORM 方式逐条更新假设10万条数据foruserinUser.objects.filter(is_activeTrue):user.last_notifiednow()user.save()# 10万次 UPDATE 语句# 正确的 ORM 方式User.objects.filter(is_activeTrue).update(last_notifiednow())# 但如果更新逻辑复杂每行的值不同ORM 就力不从心了# 手写 SQL 可以用 CASE WHEN 或临时表批量处理-- 手写 SQL一条语句完成差异化批量更新UPDATEusersSETlevelCASEWHENtotal_points10000THENgoldWHENtotal_points5000THENsilverELSEbronzeENDWHEREis_activeTRUE;2.4 数据库特有功能PostgreSQL 的 JSONB 操作、全文搜索、递归 CTE、物化视图MySQL 的空间索引、特定的锁机制——这些数据库专属能力ORM 要么不支持要么支持得很别扭。# Django 对 PostgreSQL JSONB 有不错的支持但仍有边界fromdjango.contrib.postgres.fieldsimportJSONFieldfromdjango.db.modelsimportF# 这个可以Product.objects.filter(metadata__brandApple)# 但复杂的 JSONB 操作如 jsonb_array_elements就需要 raw SQLProduct.objects.raw( SELECT p.*, elem-color as color FROM products p, jsonb_array_elements(p.metadata-variants) elem WHERE elem-stock 0 )三、决策框架什么时候用什么与其争论全用或全不用不如建立清晰的决策标准。3.1 分层策略推荐方案┌─────────────────────────────────────────────────┐ │ 应用代码层 │ ├─────────────────────────────────────────────────┤ │ 简单 CRUD │ 复杂查询/报表 │ 批量/ETL │ │ ────────── │ ────────── │ ──────── │ │ ✅ ORM │ ✅ Raw SQL │ ✅ Raw SQL │ │ 模型方法/Manager │ 封装到 Repository│ 独立脚本 │ ├─────────────────────────────────────────────────┤ │ 数据访问层Repository / DAO │ ├─────────────────────────────────────────────────┤ │ 数据库 │ └─────────────────────────────────────────────────┘3.2 具体决策矩阵场景推荐方案理由单表 CRUDORM简洁安全变更友好简单关联查询1-2层ORM select_related可读性好性能可控复杂报表/分析Raw SQL表达力强性能可优化批量数据处理Raw SQL / COPY效率差距可达百倍数据库迁移ORM Migration版本管理不可替代全文搜索/地理查询Raw SQL 数据库扩展ORM 支持有限跨库/跨服务查询Raw SQLORM 模型边界不适用3.3 代码架构让两者共存关键设计原则将 Raw SQL 封装在 Repository 层不让它泄漏到业务逻辑中。# repository/user_repository.pyfromdjango.dbimportconnectionfrom.modelsimportUserclassUserRepository:用户数据访问层 —— ORM 和 Raw SQL 在此共存# ORM 方法处理简单 CRUD staticmethoddefget_by_id(user_id:int)-User:returnUser.objects.select_related(profile).get(iduser_id)staticmethoddefcreate_user(username:str,email:str,**kwargs)-User:returnUser.objects.create(usernameusername,emailemail,**kwargs)staticmethoddefget_active_users():returnUser.objects.filter(is_activeTrue).select_related(profile)# Raw SQL 方法处理复杂查询 staticmethoddefget_user_spending_report(days:int30)-list[dict]:用户消费报表 —— 复杂聚合查询手写 SQL 更清晰高效query WITH user_spending AS ( SELECT u.id, u.username, u.email, COALESCE(SUM(o.amount), 0) as total_spent, COUNT(o.id) as order_count, MAX(o.created_at) as last_order_date FROM users u LEFT JOIN orders o ON u.id o.user_id AND o.created_at NOW() - INTERVAL %s days AND o.status completed GROUP BY u.id, u.username, u.email ) SELECT *, RANK() OVER (ORDER BY total_spent DESC) as rank, NTILE(10) OVER (ORDER BY total_spent DESC) as decile FROM user_spending WHERE total_spent 0 ORDER BY total_spent DESC; withconnection.cursor()ascursor:cursor.execute(query,[days])columns[col[0]forcolincursor.description]return[dict(zip(columns,row))forrowincursor.fetchall()]staticmethoddefbulk_update_user_levels():批量更新用户等级 —— 单条 SQL 比循环快 100 倍query UPDATE users SET level CASE WHEN total_points 10000 THEN gold WHEN total_points 5000 THEN silver WHEN total_points 1000 THEN bronze ELSE basic END, level_updated_at NOW() WHERE is_active TRUE; withconnection.cursor()ascursor:cursor.execute(query)returncursor.rowcount# services/user_service.py —— 业务层完全不知道底层是 ORM 还是 Raw SQLfromrepository.user_repositoryimportUserRepositoryclassUserService:def__init__(self):self.repoUserRepository()defget_monthly_report(self):业务逻辑只关心获取数据不关心是 ORM 还是 SQLreport_dataself.repo.get_user_spending_report(days30)# 业务处理...returnself._format_report(report_data)defregister_user(self,username,email,password):简单 CRUD 背后用的是 ORM调用方无感知userself.repo.create_user(usernameusername,emailemail)# 后续业务逻辑...returnuser四、如何终结团队的信仰之争4.1 用数据说话而非用观点当有人说ORM 性能差时不要争论直接测量# 建立性能基准测试importtimeimportdjangofromdjango.dbimportconnection,reset_queries django.setup()settings.DEBUGTrue# 开启查询日志defbenchmark_orm():测量 ORM 查询reset_queries()starttime.perf_counter()# ORM 查询userslist(User.objects.filter(is_activeTrue).select_related(profile).prefetch_related(orders).annotate(order_countCount(orders))[:1000])elapsedtime.perf_counter()-start query_countlen(connection.queries)print(fORM:{elapsed:.4f}s,{query_count}queries)returnusersdefbenchmark_raw_sql():测量等价的 Raw SQLstarttime.perf_counter()withconnection.cursor()ascursor:cursor.execute( SELECT u.*, p.*, COUNT(o.id) as order_count FROM users u LEFT JOIN profiles p ON u.id p.user_id LEFT JOIN orders o ON u.id o.user_id WHERE u.is_active TRUE GROUP BY u.id, p.id LIMIT 1000 )resultscursor.fetchall()elapsedtime.perf_counter()-startprint(fRaw SQL:{elapsed:.4f}s, 1 query)returnresults# 运行对比benchmark_orm()benchmark_raw_sql()大多数情况下正确使用 ORM加了 select_related/prefetch_related的性能与手写 SQL 差距在 10%-30% 之内这对大部分 CRUD 场景完全可以接受。而在复杂分析查询中差距可能是 5-10 倍——这时候就该切换手段。4.2 建立团队规范而非教条# 团队数据访问规范 v1.0 ## 原则 - ORM 是默认选择Raw SQL 是补充手段 - 两者通过 Repository 层统一封装 - 任何 Raw SQL 必须有注释说明为什么不用 ORM ## 必须用 ORM 的场景 - 所有表结构定义和迁移 - 单表/简单关联的 CRUD 操作 - 需要跨数据库兼容的查询 ## 允许用 Raw SQL 的场景 - 涉及窗口函数、递归CTE、复杂子查询 - 批量数据处理1万条 - 性能基准测试证明 ORM 方案慢 3 倍以上 - 使用数据库特有功能全文搜索、JSONB 深度操作等 ## 代码审查要点 - [ ] ORM 查询是否有 N1 问题 - [ ] Raw SQL 是否使用参数化防注入 - [ ] Raw SQL 是否封装在 Repository 层 - [ ] 是否有对应的测试覆盖4.3 高级工程师的思维方式真正的高级工程师不会说我信 ORM或我信 SQL他们的思考路径是1. 这个需求的数据访问模式是什么 ├── 简单 CRUD → ORM开发效率优先 ├── 复杂分析 → Raw SQL表达力优先 └── 高并发热点 → 可能需要缓存/读写分离架构优先 2. 可维护性影响多大 ├── 这段代码未来谁会改 ├── 团队的 SQL 水平如何 └── 是否容易写出测试 3. 性能是否是当前瓶颈 ├── 先测量后优化 ├── 80% 的性能问题出在缺少索引而非 ORM 开销 └── 过早优化是万恶之源五、一个真实案例电商订单系统的混合实践# models.py —— ORM 定义数据结构和关系classOrder(models.Model):usermodels.ForeignKey(User,on_deletemodels.PROTECT,related_nameorders)statusmodels.CharField(max_length20,db_indexTrue)total_amountmodels.DecimalField(max_digits10,decimal_places2)created_atmodels.DateTimeField(auto_now_addTrue,db_indexTrue)classMeta:indexes[models.Index(fields[user,-created_at]),models.Index(fields[status,created_at]),]classOrderItem(models.Model):ordermodels.ForeignKey(Order,on_deletemodels.CASCADE,related_nameitems)productmodels.ForeignKey(Product,on_deletemodels.PROTECT)quantitymodels.PositiveIntegerField()unit_pricemodels.DecimalField(max_digits10,decimal_places2)# repository/order_repository.pyclassOrderRepository:# ORM创建订单事务性操作ORM 更安全staticmethodtransaction.atomicdefcreate_order(user,cart_items:list[dict])-Order:totalsum(item[price]*item[quantity]foritemincart_items)orderOrder.objects.create(useruser,total_amounttotal,statuspending)order_items[OrderItem(orderorder,product_iditem[product_id],quantityitem[quantity],unit_priceitem[price])foritemincart_items]OrderItem.objects.bulk_create(order_items)# 批量插入returnorder# ORM查询用户最近订单简单关联staticmethoddefget_user_recent_orders(user_id:int,limit:int20):return(Order.objects.filter(user_iduser_id).select_related(user).prefetch_related(items__product).order_by(-created_at)[:limit])# Raw SQL运营日报复杂聚合 窗口函数staticmethoddefget_daily_sales_report(start_date,end_date)-list[dict]:query WITH daily_sales AS ( SELECT DATE(created_at) as sale_date, COUNT(*) as order_count, SUM(total_amount) as revenue, COUNT(DISTINCT user_id) as unique_buyers, AVG(total_amount) as avg_order_value FROM orders WHERE status completed AND created_at BETWEEN %s AND %s GROUP BY DATE(created_at) ) SELECT *, revenue - LAG(revenue) OVER (ORDER BY sale_date) as revenue_change, ROUND( (revenue - LAG(revenue) OVER (ORDER BY sale_date)) / NULLIF(LAG(revenue) OVER (ORDER BY sale_date), 0) * 100, 2) as growth_rate FROM daily_sales ORDER BY sale_date; withconnection.cursor()ascursor:cursor.execute(query,[start_date,end_date])columns[col[0]forcolincursor.description]return[dict(zip(columns,row))forrowincursor.fetchall()]# Raw SQL库存扣减需要 SELECT FOR UPDATE 精确控制锁staticmethodtransaction.atomicdefdeduct_stock(product_id:int,quantity:int)-bool:withconnection.cursor()ascursor:cursor.execute( UPDATE products SET stock stock - %s WHERE id %s AND stock %s ,[quantity,product_id,quantity])returncursor.rowcount0六、总结务实主义胜过教条主义维度ORM 擅长Raw SQL 擅长开发效率✅ CRUD 快速开发❌ 需要更多代码可维护性✅ 模型即文档⚠️ 需要良好注释查询表达力⚠️ 简单查询优秀✅ 无上限性能控制⚠️ 需要经验避坑✅ 完全可控安全性✅ 天然防注入⚠️ 需要纪律迁移管理✅ 版本化管理❌ 需额外工具最终建议ORM 是默认选择它解决 80% 的场景且降低团队认知负担。Raw SQL 是精确工具在 ORM 力不从心时果断切换。用 Repository 模式隔离让业务层不关心底层实现。用性能数据决策而非个人偏好。写进团队规范让决策有据可依而非每次代码评审都争论。记住——工具没有信仰只有适用场景。能在两种方案间自如切换才是高级工程师的标志。互动话题你的团队是如何处理 ORM 与 Raw SQL 的边界问题的有没有遇到过 ORM 性能踩坑的经历欢迎在评论区分享你的实战经验。参考资料SQLAlchemy 官方文档Django ORM 查询优化指南《Architecture Patterns with Python》— Harry Percival Bob Gregory《High Performance MySQL》— Baron Schwartz et al.Martin Fowler - ORM Hate
