电商订单库
顾客、地址、订单、订单项、商品、支付、发货 —— 每条下单链路背后的表结构,订单项里存着「下单当时的价格」。
8 张表 · 8 条关系
ER 图模板
8 套画满的数据库结构 —— 每张表都有键,每条关系都标了基数。打开就在画布上。然后把它聊成你的模型:「每张表加个 tenant_id、发货表删掉、地址从顾客里拆出来」。
挑一个模板
这里每张图都和你导入后拿到的出自同一份结构化定义 —— 没有一张是精修过的截图。卡片上的预览只画表和关系,这样缩到卡片大小还看得清结构;点开任意一张能看到完整版,字段、类型、键一个不少。「进对话微调」把表结构放进画布并打开对话面板,你的第一句话就能开始改它;「用这个模板」只把它放进编辑器,剩下的你自己来。
博客 / CMS
文章、版本、作者、分类、评论、素材,外加那张每个内容库都要有、而初版设计每次都忘的 post_tag 中间表。
8 张表 · 8 条关系
多租户 SaaS
租户、成员关系、套餐、订阅、账单,再加一张审计日志。那个几乎每张表都要带的 tenant_id 是画出来的,不是靠默契。
8 张表 · 8 条关系
在线课程
课程分章分节,选课表把学生和课程连起来,再加作业和提交。三层结构画得很干净,拿去改最省事。
8 张表 · 8 条关系
库存与仓储
按库位记的库存量、只追加的出入库流水、供应商和采购单及其明细行。这套模型让库存可审计,而不只是「当前值」。
8 张表 · 8 条关系
酒店预订
房型和具体房间分开,再加价格方案、订单、支付和评价。「类型 vs 实例」这一刀,是多数预订库第一版都会切错的地方。
8 张表 · 7 条关系
用户 · 角色 · 权限
两张中间表,加上用户组和会话。每次安全评审都要重画一遍的那套表 —— 在写 migration 之前先看成一张图更划算。
8 张表 · 8 条关系
事件分析
账号、设备、会话、一张宽事件表配一张 key-value 属性表,再加实验分组。自建埋点管道大多长这个样子。
8 张表 · 7 条关系
这些模板怎么用
1. 挑表最多的那张
有点反直觉但确实好使:选表比你需要的更多的模板。看着图删掉一张表是两秒钟的事,而 migration 上线之后才发现少了一张中间表,那是另一个下午。
2. 打开 —— 整套结构已经画好了
页面加载完图就在画布上:每张表都有主键,外键标好了,每条关系都带基数,多对多也已经拆成了中间表。
3. 把它聊成你的模型
打开对话面板,用句子纠正它:「每张表加个 tenant_id、发货表删掉、地址从顾客里拆出来、订单到支付改成一对多」。助手改的就是你眼前这套结构化的表,所以每一轮返回的是重画后的版本,而不是重新猜一张。
4. 手动收尾并导出
分屏视图把 Mermaid 源码和预览摆在一起,做最后几处微调。然后:文档里会被放大的用 SVG,幻灯片和工单用 PNG,或者把源码提交到它描述的那份 migration 旁边。
ER 图是什么
实体关系图画的是存下来的数据:有哪些表、每张表有什么字段和类型、哪些字段是键,以及一边的多少行对应另一边的多少行。它回答「存了什么、之间怎么连」—— 不是「代码长什么样」(那是类图),也不是「用户下单时依次发生了什么」(那是时序图)。
在写 migration 之前先画一张,理由在于基数。「一个订单有一笔支付」听上去没什么可争的,直到你把它画出来、必须在一对一和一对多之间选一个 —— 而这个选择决定了半年后支持部分退款时要不要改表。ER 图的价值,大半是在画的过程中被榨出来的。
Mermaid 的 erDiagram 覆盖了设计文档需要的东西:带类型的字段、PK 和 FK 标记、有名字的关系,以及完整的鱼尾基数记号。它不是一种 DDL —— 没有索引、没有约束、没有默认值。对一份真的会被人读完的文档来说,这个层次刚好;剩下的交给 migration 文件。
ER 图语法速查
ER 图的信息量几乎全在这六样东西上。真正需要动脑的是基数 —— 某一端有没有那个鱼尾,决定了这套结构是能扛住真实数据,还是三个月后要改表。
实体与字段
Entity { ... }一个方框就是一张表。里面每一行是一个字段,写法是**先类型后名字** —— 和大多数编程语言相反,也是这套语法最常被写错的地方。
主键与外键
PK / FK字段后面加 PK 表示主键,加 FK 表示外键,一个字段可以同时是两者。把 FK 标出来,那些连线才是可核对的,而不只是装饰。
一对多
||--o{最常用的一种。按符号逐个读:左边 || 是「恰好一个」,右边 o{ 是「零个或多个」。一个顾客可以下任意多个订单,而每个订单只属于一个顾客。
一对一
||--||两边都恰好一个。真正的一对一很少见 —— 如果一行永远对应且只对应一行,先问问这两张表是不是本该是一张。可选的扩展信息表是比较诚实的用法。
多对多
中间表不要画成一根线。中间放一张关联表,再画两条一对多进去 —— 那些额外字段(角色、加入时间、排序)最后都得住在这张表里。
关系标签
: "holds"冒号后面的文字给这条关系命名,而且是必须写的。用一个从左往右读得通的动词 ——「仓库 持有 库存量」—— 图才能读成句子,而不是一张没名字的连线网。
常见问题
导入之后怎么改?
两条路,各管一类改动。对话管「结构性」的:「每张表加个 tenant_id」「地址从顾客里拆出来」「跟物流有关的全删掉」—— 说一轮重画一张。分屏编辑器管「精细」的:字段名打错了、类型换一个、关系标签改个词。多数人的用法是:导入 → 在对话里把形状聊定 → 回编辑器抛光。
助手真的「看得懂」导入进来的表结构吗?
看得懂,因为模板是结构化数据,不是一张图片或者一坨文本。导入的表、字段和关系直接成为这轮对话的工作状态,所以「把发货表删了」删的就是那张表以及挂在它身上的关系 —— 助手不是在根据一段描述重新猜你的图。
多对多怎么画?
不直接画,而是把它拆开。两个实体中间放一张关联表,两边各画一条一对多进去 —— 就像 CMS 模板里 PostTag 夹在 Post 和 Tag 中间那样。这和数据库里实际存的东西一致,而且那些额外字段(角色、加入时间、排序)也有地方放了。
ER 图和类图有什么区别?
ER 图描述存下来的数据:表、字段、键和基数,不涉及行为。类图描述代码:带方法的类型,有继承、有接口。你画的东西最终对应一次 schema 迁移,那是 ER 图;它有方法,那是类图。
该用一对一还是一对多?
问一句:第二行有没有可能合法地出现。「一个订单一笔支付」在你允许分次付款或者重试之前成立,一旦允许,它其实一直都是一对多。拿不准时,选一对多是更便宜的错:现在多一次 join,而反过来是以后多一次 migration。
能直接生成 SQL 吗?
不能,ER 图刻意停在 DDL 之前。它承载表、字段、类型、键和基数,但不含索引、约束、默认值和排序规则。它是拿去评审的设计产物;形状定下来之后,再照着它写 migration。
一张图里放多少张表比较合适?
限制来自可读性,不是工具。超过十来张表,关系线就开始互相穿插,没人会去跟着看。按业务域拆开 —— 订单一张、商品一张 —— 再从父文档链过去。这里的模板刻意都是八张表。