图表图表类型
AI ER 图生成器
描述表和它们之间的关系,拿一张带主键外键的 ER 图。
点一个试试 —— 会直接带进生成器
博客数据库结构:users(id, email, name, created_at)、posts(id, user_id FK, title, body, published_at)、comments(id, post_id FK, user_id FK, body, created_at)。一个用户可以写多篇文章,一篇文章可以有多条评论,一个用户可以留多条评论。
Try it →多租户 SaaS:organizations(id, name, plan)、users(id, org_id FK, email, role)、workspaces(id, org_id FK, name)、documents(id, workspace_id FK, author_id FK, title, content)。每个组织有多个用户和 workspace,每个 workspace 有多篇文档,用户可以写多篇文档。
Try it →电商结构:customers(id, email)、products(id, sku, name, price)、orders(id, customer_id FK, total, status, placed_at)、order_items(id, order_id FK, product_id FK, quantity, unit_price)。一个客户下多个订单,每个订单包含多个订单项,每个订单项指向一件商品。
Try it →产品分析结构:users(id, anonymous_id, identified_at)、events(id, user_id FK, name, timestamp, properties json)、sessions(id, user_id FK, started_at, ended_at, device)、page_views(id, session_id FK, url, referrer, duration_ms)。
Try it →适用场景 AI ER 图生成器
设计新表结构
写第一个 migration 之前,先把表、字段、关系画出来。字段怎么命名、是一对多还是多对多,对着一张图讨论,比散在五个群里各说各的强。
拆表和重构
要把 users 一张表拆成 users、profiles、preferences?在图上标出哪些字段搬到哪。前后两张图一对比,评审的人一眼就能看出哪个外键断了。
新人上手和架构文档
新人第一个问题往往是「钱记在哪张表里」。README 里紧挨着 migration 放一张 ER 图,比让他翻四十个 model 文件快。
审计和合规评审
等保、SOC2、GDPR 评审都会问个人信息存在哪、怎么流转。在 ER 图上把这些字段标出来,比给一张字段清单表格清楚。
范式和性能的取舍
为了读得快要不要反范式?要不要加一张预先 join 好的表?把三范式版本和反范式版本并排放,讨论起来快得多。
用对话模式画 ERD —— 从一句含糊的话开始
一句话描述 schema,基数只能靠模型猜:一对多还是多对多,要不要中间表,外键能不能为空。对话模式只就那个会改变整张表结构的基数问一句,剩下的直接画,画完再把猜的地方一条条列出来给你划掉。下面是一套招聘系统的表结构,起点是一句故意含糊的话。
- 加了一张 DEPARTMENT 表,并在 JOB 上挂了 department_id
- 按面试小组来处理:一场面试几个面试官各写各的评价,于是有了 INTERVIEW_PANELIST
- 给 APPLICATION 加了 stage 字段(screening / onsite / offer / rejected)
- 给 CANDIDATE、JOB、APPLICATION 都加了 created_at
- 主键统一用 bigint,外键类型跟着对齐
四句话画出了两张中间表、一张可以重复投递的申请表和一张带版本的 offer 表 —— 「画一下我们招聘系统的数据库」这句话里一个都没有。同样一句话直接一次性生成,大概率给你一个 candidate.job_id、一场面试一个面试官,外加每张表都挂着的 created_at,还得你自己一条条删。
详细说明
ER 图用来讲清楚数据存成什么样,而不用直接甩一段建表语句给对方看。它把每张表画成一个框,列出字段和类型,标出主键外键,最关键的是把表之间是一对一、一对多还是多对多标清楚。
三个时候用得上:写第一个 migration 之前先把结构画出来给大家评审;新人接手已有项目的时候;技术方案里要解释数据模型为什么长这样的时候。要拆表或者合表的时候也好用 —— 可以直接在图上标出哪些字段搬到哪。
Mermaid 的 erDiagram 用的是鸦爪符号,支持字段类型、主键外键标记和关系上的说明文字,画设计文档够用了。它不画索引、不画键之外的约束,也不管物理存储 —— 这些要看 dbdiagram.io 或者 ORM 自带的可视化。但大部分时候你只是想说清楚「数据长什么样」,一张跟 migration 放在一起的纯文本 ER 图正好。
自己试一下?
常见问题
AI ER 图生成器怎么用?
用大白话描述有哪些表、表之间什么关系,比如「用户发文章,文章下面挂评论,评论也属于用户」,直接生成一张 Mermaid ER 图,带实体、主键、外键,以及一对一 / 一对多 / 多对多关系。不用学 ER 图语法,也不用打开建模工具。字段是怎么补出来的?
从上下文推。你说「用户有邮箱和密码」,这两个就成为字段;你说「文章有很多评论」,评论表上就多一个 post_id 外键。主键默认给 id;描述里提到审计或者时间的,会自动补 created_at 和 updated_at。字段类型按名字猜 —— email 给 varchar,price 给 decimal,is_active 给 boolean。多对多和中间表怎么画?
照常说就行:「用户可以收藏文章」「一个标签打在多篇文章上,一篇文章有多个标签」。它会自己加一张中间表,带联合主键和两边的外键。也可以直接指定:「加一张 favorites 表,字段是 user_id 和 post_id」,它就按你说的形状画。怎么放进 migration 文档或者 PR 里?
预览区状态栏可以导出 SVG 或 PNG。SVG 适合文档、README、Confluence,缩放清楚而且文字能搜;PNG 适合聊天工具、Notion 和邮件。也可以直接复制底层的 Mermaid 源码,GitHub markdown、Notion、Obsidian 都能渲染,以后要改还是改文字。继承、多态这类模式怎么表达?
Mermaid 的 ER 图没有继承箭头,所以它用实际的建表模式来表达:单表继承画成一张表加一个 type 字段;类表继承画成父表加若干子表,子表反向指回父表;多态关联画成两个可空外键加一个 type 字段。要严格的 UML 语义,用类图那个页面。免费吗?要注册吗?
快速模式免费,不用注册,导出的图上没有水印,按 IP 有每天的次数上限。对话模式也免费,但要登录 —— 多轮对话的上下文得跟账号绑在一起。用量特别大、需要单独容量的,走联系页说一声。
不知道怎么描述?
对话模式里 AI 会先问你两三个问题 —— 谁参与、发生什么、异常分支怎么走 —— 弄清楚了再动笔。
想画得更规范?
教程里讲了常用符号、几种基本结构、九条画法规范,还有可以直接拿去用的 prompt 模板和真实业务例子。