AI ERD 生成器

描述实体和关系,得到一张 Mermaid ERD 含主外键。

试一下这些示例 —— 点击后自动进生成器

博客数据库结构: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)。一个用户可以写多篇文章,一篇文章可以有多条评论,一个用户可以留多条评论。

SaaS 多租户结构

多租户 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 有多篇文档,用户可以写多篇文档。

电商:商品/订单/订单项

电商结构: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)。一个客户下多个订单,每个订单包含多个订单项,每个订单项指向一件商品。

分析事件表结构

产品分析结构: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)。

什么时候用它

实体关系图(ERD)是你**不用直接甩 DDL** 给读者也能讲清数据库结构的方式。它把实体画成表格,列出字段类型、主外键 —— 关键是清楚展示了关系的**基数**(一对一、一对多、多对多)。什么时候用 ERD?**新建结构 + 写 migration 之前** —— 先把结构画出来大家评审;**onboarding 新工程师**到已有代码库时;**架构文档**里论证"数据模型为什么长这样"。**规划迁移或重构**时也无比有用 —— 你可以标出哪些表将被合并或拆分。 Mermaid 的 erDiagram 语法用"鸦足记法"(crow's foot notation),支持字段类型、PK/FK 标记、关系标签 —— 对真实设计文档已经够用。它的短板:不显示索引、超出键的约束、物理存储细节。这些交给 dbdiagram.io 或 ORM 的图谱可视化工具去做。但对于 90% 的"来说说这个数据长什么样"场景,一份跟迁移文件一起 commit 的纯文本 ERD 完美够用。

AI ERD 生成器

试一下这些示例 —— 点击后自动进生成器

什么时候用它

相关工具