3.5 数据库与 ORM
3.5 数据库与 ORM
本节摘要：Django 的 ORM 是"写 Python 类代替 SQL"的典范。本节讲清模型的写法、迁移机制（改模型 → 生成迁移 → 执行）、常用查询操作，以及"ORM 让数据操作变成对象操作"的核心理解。
核心问题
阅读完本节，你应当能够：
- 定义模型类
- 理解迁移机制
- 执行增删改查
- 使用常用查询
- 理解 ORM 的价值
一、问题与直觉
"Django 怎么写数据库操作？"——不写 SQL，写 Python：定义一个模型类（类名是表名，属性是字段），框架自动建表。查数据用"类名.objects"——数据操作全程对象化，是 Django 最舒服的地方。
二、核心原理
ORM 的工作方式：
2.1 模型定义
# models.py from django.db import models class User(models.Model): name = models.CharField(max_length=50) age = models.IntegerField() created_at = models.DateTimeField(auto_now_add=True)
2.2 迁移机制
python manage.py makemigrations # 生成迁移（记录模型变更） python manage.py migrate # 执行迁移（更新数据库）
💡 关键直觉：迁移是"模型变更的流水账"——改模型 → 生成迁移 → 执行，数据库跟着代码走。团队协作时，迁移文件让所有人同步数据库结构。
三、工程实践要点
3.1 常用操作
| 操作 | 写法 |
|---|---|
| 新增 | User.objects.create(name="张三") |
| 查询全部 | User.objects.all() |
| 条件查询 | User.objects.filter(age__gt=18) |
| 修改 | obj.name = "李四"; obj.save() |
| 删除 | obj.delete() |
3.2 在视图里用数据
def user_list(request): users = User.objects.all() data = [{"id": u.id, "name": u.name} for u in users] return JsonResponse(data, safe=False)
⚠️ 常见坑：改了模型忘记迁移。模型改了但没 migrate，查询报"表不存在"或"列不存在"——改模型后先迁移再测试。
要点速记
- 要点一：模型类 = 表定义
- 要点二：迁移让数据库跟着代码走
- 要点三：.objects 提供增删改查
- 要点四：filter 支持条件查询
- 要点五：改模型必迁移
- 要点六：数据操作全程对象化
数据通了，最后一节上后台——管理后台与部署。
常见疑问
Q1：Django ORM 的"模型即表"是怎么实现的？
你写一个继承 models.Model 的类，类名对应表名、类属性对应字段、字段类型决定列类型。框架在迁移时把这些 Python 定义翻译成建表 SQL。比如 CharField 对应可变长字符串列，IntegerField 对应整数列，DateTimeField 对应日期时间列。模型是 Django 数据层的"唯一真相"，改字段就在模型里改，然后通过迁移同步到数据库——数据库结构始终跟代码走。
Q2：查询集（QuerySet）是懒加载的吗？
是。像 User.objects.all()、filter() 这类查询，返回的是一个"查询集"对象，它不会立刻执行 SQL，而是在真正用到结果时才查询数据库（比如遍历、转为列表）。这个设计的好处是：你可以链式拼接多个过滤条件，框架最终合成一条 SQL 执行。理解懒加载，你就能解释"为什么查询不报错、数据却是旧的"这类奇怪问题——可能是结果还没真正求值。
Q3：filter 和 exclude 怎么用？
filter 是"筛出满足条件的"，exclude 是"排除满足条件的"（相当于 SQL 的 NOT）。两者都返回查询集，可以链式叠加：先 filter 年龄大于 18，再 exclude 城市在北京。字段名加双下划线可以表示"跨字段查询"（比如 age__gt=18 表示大于 18、age__lt=30 表示小于 30），这是 Django ORM 常用而强大的一点。
Q4：ORM 和手写 SQL 怎么配合？
ORM 覆盖日常 90% 的需求（增删改查、简单统计），复杂场景（多表连查、窗口函数、特殊聚合）ORM 写起来绕，可以退回到手写 SQL（用 raw 查询或原生 SQL）。实践原则：默认 ORM，复杂再手写。用 ORM 保证安全（自动参数化、防注入）和开发效率，用 SQL 解决 ORM 表达不了的场景，两条腿走路。
工程实践要点
动手建议：完整走一遍"模型—迁移—查询"闭环：在 models.py 定义一个带几个字段的模型，makemigrations 生成迁移、migrate 建表，然后在 Django shell（python manage.py shell）里执行增删改查：创建几条记录、查询全部、按条件过滤、修改一条、删除一条。通过 shell 你可以直接体验 ORM 的每个方法返回什么、什么时候真正查库。再在视图里用同样的查询返回数据——这一步做完，Django 的数据链路你就通了。
实战演练：用 ORM 完成数据闭环
本节练习的目标，是完整走一遍"模型定义到增删改查"，并养成迁移习惯。步骤如下：
第一步，定义一个较完整的模型：包含字符串字段、整数字段、日期字段（自动记录创建时间）。验收标准：字段类型符合数据类型语义。
第二步，执行迁移，确认表已创建。然后打开数据库查看表结构，对照模型类逐字段核对。验收标准：表结构与你定义的模型一致。
第三步，用命令行交互环境做增删改查。创建几条记录，查询全部，按条件过滤（比如年龄大于 18），修改一条，删除一条。每一步都打印结果确认。验收标准：每个操作都有预期输出，你能看懂每个方法返回什么。
第四步，在视图里使用同样的查询。写一个返回数据列表的接口，通过浏览器访问。验收标准：接口返回数据库里的真实数据。
第五步，做一次"改模型必迁移"的演练。给模型加一个新字段，不迁移直接访问接口，观察报错；然后生成并执行迁移，再访问，确认正常。验收标准：你亲身体会到"模型和数据库必须同步"这条规则。
第六步，写一个带条件的查询方法，观察它生成的查询行为是否符合预期（数据条数是否正确）。验收标准：条件查询结果准确。
六步走完，Django ORM 的日常操作你就都上手了。更重要的是，你建立了"模型一变、迁移必跟"的肌肉记忆。
一句话记忆
Django ORM 让数据操作变成对象操作：模型定义表、迁移同步库、对象方法做增删改查。亲手走一遍"定义—迁移—增删改查—视图调用"，再体验一次"忘记迁移的报错"，ORM 就真正属于你了。