你还在用 ORM？2026 年最潮数据库玩法是“裸奔+数据类”！
话说，编程圈里有个老规矩：写代码连数据库，得靠 ORM。
啥是 ORM？就是那种能把数据库里的表格自动变成你代码里“对象”的魔法工具。比如你查一个订单，ORM 就会给你返回一个 Order 对象，你直接 order.customer_email 就能拿到客户邮箱，不用管底层 SQL 怎么写。
这玩意儿用了二十多年，大家都觉得理所当然，就像吃火锅必须配麻酱一样。
但就在 2026 年初，有个叫迈克尔·肯尼迪（Michael Kennedy）的老程序员突然拍桌子：“我不玩了！我要裸奔！”
他宣布：从此以后，数据库查询一律手写原生语句，再配上 Python 的 dataclass（数据类），搞出一套新玩法——Raw+DC 模式。
Raw 是“原始”，DC 是“Dataclass”的缩写。合起来就是：原始查询 + 数据类。
ORM 曾经是神，现在却成了“祖传包袱”
先说说 ORM 为啥火了二十多年。它有四大神技：
第一，类型安全。你定义一个 Order 类，字段清清楚楚，IDE（比如 PyCharm）一敲点号，自动弹出 customer_email、order_number，根本不会拼错。
第二，防黑客。你传用户输入进去，ORM 自动帮你转义，不怕“小鲍比表”（Bobby Tables）那种 SQL 注入攻击——就是那种在用户名里写 DROP TABLE users; 的阴招。
第三，复杂查询变简单。你想查“所有已付款且地址在加州的订单，并附带客户信息和商品列表”，ORM 能让你用几行 Python 代码搞定，不用写半页 SQL。
第四，代码整洁。所有数据库操作都围绕“类”展开，逻辑清晰，新人接手也不懵。
所以，ORM 简直是程序员的贴心小棉袄。但问题来了——这件棉袄，穿久了开始掉毛、发霉、还卡bug。
迈克尔用过两个 MongoDB 的 ODM（文档型 ORM），先是 mongoengine，后来换 Beanie。结果呢？mongoengine 好几年没更新，连异步都不支持；Beanie 虽然新一点，但 2025 年全年只发了几次版本，GitHub 上堆着 91 个未处理 issue 和 18 个 PR，其中一个 bug 还是他自己追了三年都没修好的。
这就尴尬了。你辛辛苦苦写的系统，底层依赖一个快凉透的库，哪天它彻底没人维护，你的项目就卡死在历史版本里，动弹不得。就像你买了辆限量跑车，结果厂家倒闭了，连颗螺丝都找不到替换的。
而 Raw+DC 呢？只依赖数据库官方驱动，比如 pymongo。这玩意儿是 MongoDB 官方亲儿子，每月下载量 7420 万次，Beanie 才 140 万。pymongo 几周前刚发新版，稳如老狗。就算哪天真不行了，换 motor（另一个异步驱动）也只要改几行代码，因为查询语法完全一样。
所以，Raw+DC 的第一个狠话就是：别把命押在一个小众框架上，数据库原生才是永动机。
AI 编程助手更爱“原味”查询，不是花里胡哨的 ORM
现在谁还手写复杂查询？早喊 Claude、Copilot 这些 AI 助手上场了。但你猜怎么着？这些 AI 更擅长写原生数据库语句，而不是 ORM 代码。
为啥？因为训练数据多啊！全世界用 pymongo 写 MongoDB 查询的人，比用 Beanie 的多 53 倍。Node.js、PHP、Java、Go……所有语言调 MongoDB 都用同一套查询语法。AI 看过的例子，可能是 Beanie 的一千倍。
举个栗子：你想查订单号为 “ORD-12345” 的客户邮箱。用 pymongo 写：
python
db = get_db(ctx)
doc: dict = db.orders.find_one(
{'order_number': order_number},
{'customer_email': 1, '_id': 0}
)
这段代码，AI 见过无数遍。但如果你用 Beanie 写：
python
order = await Order.find_one(Order.order_number == order_number).project(EmailProjection)
AI 可能就得愣一下：“EmailProjection 是啥？我训练时没见过这玩意儿。”
所以，Raw+DC 的第二个狠话是：让 AI 写它最熟的菜，别逼它做分子料理。
没了 ORM，类型安全怎么办？答案：数据类来救场！
很多人一听“手写查询”，立马慌了：“那我的 IDE 自动补全呢？我的类型检查呢？我的 pyright、mypy 呢？”
别怕！Python 有个神器叫 dataclass（数据类）。你定义一个类，加个 @dataclass 装饰器，它就自动变成结构清晰、可实例化、带类型提示的“数据容器”。
比如：
python
from dataclasses import dataclass
from datetime import datetime
from bson import ObjectId
@dataclass(slots=True)
class Order:
id: ObjectId
order_number: str
customer_email: str
status: str
total_cents: int
item_count: int
created_at: datetime
updated_at: datetime
shipping_address: Address
payment: Payment
line_items: list[LineItem]
status_history: list[StatusEntry]
这不就是 ORM 里的实体类吗？对！但它没绑定任何数据库逻辑，纯粹是个“数据盒子”。你从数据库查出来的是字典（dict），然后写个转换函数，把它塞进这个盒子里：
python
def order_from_doc(doc: dict) -> Order:
return Order(
id=doc['_id'],
order_number=doc['order_number'],
customer_email=doc['customer_email'],
status=doc['status'],
total_cents=doc['total_cents'],
item_count=doc['item_count'],
created_at=doc['created_at'],
updated_at=doc['updated_at'],
shipping_address=Address(doc['shipping_address']),
payment=Payment(doc['payment']),
line_items=[LineItem(li) for li in doc['line_items']],
status_history=[StatusEntry(sh) for sh in doc['status_history']],
)
看起来有点啰嗦？没错！但这正是 AI 最擅长干的活。你改个字段，喊一声 Claude：“帮我更新 order_from_doc 函数”，三秒搞定。而且这代码透明、无魔法、零依赖，出了 bug 一眼就能定位。
所以，Raw+DC 的第三个狠话是：类型安全不是 ORM 的专利，数据类 + 转换函数，轻装上阵照样飞。
性能实测：Raw+DC 快到 ORM 怀疑人生
嘴上吹牛没用，得看跑分。迈克尔搞了个 GitHub 仓库，专门比速度：
> github.com/mikeckennedy/orm-vs-raw-mongo
里面用三种方式查 MongoDB：
- 纯 pymongo（字典进出）
- Raw+DC（字典转 dataclass）
- Beanie（现代 ODM）
- mongoengine（老古董 ODM）
结果？Raw+DC 几乎和纯 pymongo 一样快，而 Beanie 慢 20%~30%，mongoengine 直接慢 2 倍以上。
为啥？因为 ORM 要干太多事：验证字段、触发钩子、管理缓存、处理关系……这些在 Raw+DC 里统统砍掉。你只在需要的时候，把字典转成 dataclass，开销微乎其微。
所以，Raw+DC 的第四个狠话是：性能不是玄学，少一层抽象，快一分自由。
安全吗？当然安全！只要你别作死
有人问：“手写查询会不会被注入攻击？”
会！但前提是你作死。
SQL 里，永远用参数化查询：
python
cursor.execute("SELECT * FROM orders WHERE order_number = %s", (order_number,))
MongoDB 里，永远把用户输入当字符串，别让它变成字典：
python
# 正确：用户输入是字符串
db.orders.find_one({"order_number": user_input})
# 错误：用户输入是字典，可能变成 {"$gt": ""} 绕过验证
db.orders.find_one(user_input_dict) # 千万别这么干！
ORM 的安全性，本质也是靠参数化实现的。Raw+DC 只要你遵守规则，一样安全。甚至更安全——因为你清楚每行代码在干嘛，不像 ORM 里藏着一堆你看不见的魔法。
所以，Raw+DC 的第五个狠话是：安全不是框架给的，是你自己守的。
怎么上手？三步走，十分钟搞定
想试试 Raw+DC？超简单。
第一步：启动 MongoDB（用 Docker 最方便）：
bash
docker pull mongo:latest && docker run -d --rm -p 0.0.0.0:27017:27017 --name mongosvr mongo:latest
第二步：克隆 benchmark 仓库：
bash
git clone https://github.com/mikeckennedy/orm-vs-raw-mongo.git
cd orm-vs-raw-mongo
第三步：用 uv（新一代 Python 包管理器）安装并运行：
bash
uv sync
uv run main.py run
跑完你就能看到性能对比图。紫色线（Raw+DC）紧贴蓝色线（纯 pymongo），橙色（Beanie）和绿色（mongoengine）远远落在后面。
这不是倒退，是返璞归真
有人嘲讽：“你这不是自己造了个简陋 ORM 吗？”
对！但这是可控的、透明的、可替换的简陋 ORM。
ORM 像一辆全自动豪华轿车，但一旦抛锚，你连引擎盖都打不开。Raw+DC 像一辆改装摩托——零件少、速度快、坏了自己拧螺丝就能修。而且，AI 助手就是你的专属 mechanic，随时待命。
2026 年，编程不再是“用最复杂的框架显得自己很牛”，而是“用最简单的工具解决问题”。Raw+DC 正是这种思潮的体现：去依赖、重控制、信 AI、保类型。
总结：Raw+DC 的五大核心优势
1. 依赖极少：只靠数据库官方驱动，远离小众 ORM 的维护风险。
2. AI 友好：原生查询语法通用，AI 生成准确率飙升。
3. 类型安全：dataclass 提供完整 IDE 支持和静态检查。
4. 性能卓越：接近裸查速度，远超传统 ORM。
5. 安全可控：只要遵循参数化原则，安全无虞。
作者背景介绍
迈克尔·肯尼迪（Michael Kennedy）是资深 Python 开发者、播客主、教育者，长期活跃于 Python 社区，创办了 Talk Python 和 Python Bytes 等知名技术播客。他拥有超过 25 年软件开发经验，曾大力推广 ORM 使用，但在 2026 年基于实际项目痛点与 AI 编程趋势，提出 Raw+DC 新范式，引发社区广泛讨论。
独特性评价
这篇文章的独特价值在于：将“技术选型”从教条主义拉回实用主义。它不是否定 ORM 的历史贡献，而是基于 2026 年的新现实——AI 编程普及、小众框架维护风险加剧、性能敏感场景增多——提出一种更轻量、更可控、更面向未来的数据访问模式。
其最大创新并非技术本身（raw query + dataclass 早已存在），而是系统性论证了该组合在当代开发环境中的综合优势，并用真实 benchmark 和可复现代码支撑观点，极具说服力。