为什么需要数据库
内存和文件适合临时状态；需要长期保存、查询、关联和并发修改的数据，应该进入数据库。
- 能从产品需求识别哪些数据必须被长期保存。
- 记录、表、字段、主键和关系
- 为待办应用画出 User、Project、Task 三个实体及关系。
- 完成 5.6「把后端概念迁移到 Java / Spring Boot」
FOUNDATION
必须理解
内存和文件适合临时状态；需要长期保存、查询、关联和并发修改的数据，应该进入数据库。
内存数组会在进程重启时消失，文件也难以安全支持并发查询。数据库管理长期事实、查询、并发和约束，是产品从演示进入真实使用的关键。
内存像桌面便签，应用关闭就可能丢；数据库像有目录、规则和管理员的档案馆，多个人可以按编号查找，同时防止关键资料缺失。
任务应用把用户、任务和完成状态保存在数据库。用户刷新、换设备或服务器重启后，属于他的任务仍能按权限取回。
记录、表、字段、主键和关系
数据能在应用关闭、服务器重启后继续存在，这就叫持久化。数据库不只是一个大盒子，它还会处理索引、约束、事务和多人同时访问。
基础概念
记录是一件业务事物的一组数据，表组织同类记录，字段描述每条记录的属性，主键唯一识别记录，关系则通过标识把不同表中的记录连接起来。
进一步理解
一行任务记录可包含 id、title、done 与 ownerId；主键 id 让更新目标不依赖可能重复的标题，ownerId 连接到用户表。
数据模型从业务对象和规则出发，不从页面布局出发。一个页面可展示多类记录，同一记录也能出现在多个页面。
User 与 Task 分表保存，一个用户对应多条任务；查询当前用户任务时通过 ownerId 建立归属边界。
表不是电子表格页面，关系也不等于把完整用户对象复制到每条任务。通常保存稳定标识并在查询时连接。
这一小节记住：先识别业务实体、唯一身份和关系，再决定表与字段。
持久化、并发和数据一致性
数据模型是在回答“产品里有哪些真实东西，它们怎么关联”。任务有 id、标题、完成状态和所属用户，一个用户可以拥有很多任务。
基础概念
持久化表示数据在当前进程结束后仍然存在；并发表示多个操作可能同时发生；一致性表示数据在规则约束下保持可解释和有效。
进一步理解
内存数组随服务器重启消失，文件写入虽能保留，却难以安全处理多人同时修改、查询和约束。数据库提供事务、锁与约束来协调这些问题。
一致性不是所有副本每一瞬间绝对相同，而是系统明确允许什么状态、何时可见以及冲突如何解决。业务规则必须落实到合适的服务与数据库边界。
两台设备同时完成同一任务时，数据库应以明确更新条件处理，避免后写请求把对方的新状态意外覆盖。
把数据写进磁盘不等于拥有数据库保证；一个 JSON 文件持久存在，却可能在并发写入时损坏或丢失更新。
这一小节记住：数据库的价值不仅是保存，还包括在多人和失败环境中维护规则。
结构化数据与图片文件的不同存储方式
页面样式改坏了还能重新发布，生产数据删错了却可能找不回来。所以数据库修改要更谨慎，备份、权限和迁移测试都不能省。
基础概念
结构化数据具有稳定字段并需要筛选、关联与约束，适合关系型数据库；图片、视频等大文件通常存入对象存储，数据库保存文件标识、地址、类型和归属信息。
进一步理解
把大文件直接塞进普通业务表会放大备份、查询和传输成本。对象存储擅长保存二进制内容，数据库擅长管理谁拥有它、如何查找和是否有效。
选择不是按扩展名机械决定。小型二进制有时可入库，JSON 也可能存数据库；关键是访问模式、大小、事务需求和生命周期。
任务附件上传到对象存储，TaskAttachment 表保存 key、文件名、大小、上传者和 taskId；删除任务时按策略清理对应对象。
对象存储地址不应自动公开。即使文件不在数据库，下载授权、删除规则和生命周期仍要由应用明确管理。
这一小节记住：内容本体与描述内容的元数据，可以由不同存储各取所长。
AI COLLABORATION
AI 如何参与
让 AI 从用户操作反推需要保存的实体、字段、关系和状态，再讨论表结构。
推荐协作顺序
- 1
把产品需要长期保留的事实列给 AI，让它先分实体。
- 2
用几条真实查询反推字段和关系，删除只为页面排版存在的数据。
- 3
让 AI 找出敏感字段、唯一性和删除影响，再决定模型。
我是数据库零基础学生。请以“个人学习任务应用”为例，用表格解释内存数组、JSON 文件、关系型数据库三种存储方式在重启、多人并发、查询、约束、备份方面的差异。再给出 User 与 Task 的最小关系图。
说明数据库解决的是持久化与一致性问题，不把它简化为更大的数组；关系图应明确主键和归属。
人工检查清单
- 确认模型没有把密码明文保存，也没有用可变标题作为唯一身份。
- 让 AI 从真实用户操作反推实体、字段、关系与约束，并逐项说明存在理由。
- 用创建、查询、并发修改和服务器重启四种场景验证模型，而不是只看表图好不好看。
COMMON TRAPS
常见误区
错误不是需要隐藏的失败，而是帮助你看清系统边界的证据。下面三类问题在 AI 辅助学习中最常出现。
把数据库当成永久数组
- 你会看到
- 只考虑存进去，不考虑多人同时修改、约束和恢复。
- 为什么发生
- 把数据库当大 JSON 会忽略唯一约束、关系、并发和事务，规模稍大就需要在应用里重复实现数据库能力。
- 怎样纠正
- 同时设计身份、关系、并发和备份，不把持久化简化成写文件。
页面有什么就建什么字段
- 你会看到
- 为了显示“已完成 3 条”，额外保存一个随时可能失真的计数。
- 为什么发生
- 先让工具生成大量表会把尚未确认的业务假设固化，关系错误后迁移成本迅速上升。
- 怎样纠正
- 先保存业务事实，能从事实计算的结果通常不用重复存。
用标题充当任务身份
- 你会看到
- 两个同名任务无法区分，改标题后关联也断了。
- 为什么发生
- 把图片正文和所有业务字段混在同一表中，会让查询与备份承担不必要的大对象成本。
- 怎样纠正
- 使用稳定且唯一的 id，标题只是可以修改的属性。
HANDS-ON
动手任务
为待办应用画出 User、Project、Task 三个实体及关系。
- 完成 5.6「把后端概念迁移到 Java / Spring Boot」
跟着做
- 01
列出任务应用需要跨刷新保留的事实。
- 02
把事实分为 User 与 Task 两类实体。
- 03
为每类写字段、类型、是否必填和唯一性。
- 04
画出一个用户拥有多条任务的关系。
- 05
用三个用户问题检验模型能否回答。
能从产品需求识别哪些数据必须被长期保存。
加入任务标签，比较把标签写成逗号字符串与建立关系表的优缺点。
离开本课前，自问四件事
- 记录、表、字段、主键和关系如何描述一条任务？
- 持久化、并发和一致性分别解决什么问题？
- 为什么一个能保存 JSON 的文件仍不等于数据库？
- 任务附件的文件内容与元数据应如何分工存储？
确认完成后，会同步更新学习中心的课程学习进度。