dbdiagram.io 有付费内容

dbdiagram.io 是一个用文本 DSL（DBML）描述数据库结构、再自动渲染成关系图的在线工具。它适合需要快速把表结构画出来、导出 SQL 或分享给团队评审的开发者。核心工作流是：在左侧写 DBML 定义表和字段，右侧实时生成图，用 ref 声明外键后自动出现连线，最后导出或分享。下面按这个顺序说明具体做法和容易卡住的地方。

用 DBML 定义表、字段与主键

DBML 的基本单位是 Table，字段写在花括号里，每行一个。主键用 [pk] 标注，自增用 [increment]，非空用 [not null]，注释用 //。

Table users {
  id integer [pk, increment]
  email varchar [not null, unique]
  created_at timestamp
}

Table orders {
  id integer [pk, increment]
  user_id integer
  total decimal
  status varchar
}

输入这段后，右侧会立刻出现两张表。字段类型是自由文本，工具不会校验它是否匹配某个具体数据库，所以写 integer、int、bigint 都能画出来，但导出 SQL 时会按你写的原样输出——这一点在需要精确 DDL 时要留意。

用 ref 声明外键，让连线自动生成

关系图的价值在于表之间的连线。DBML 用 ref 表达外键，写法有两种：

// 方式一：单独一行声明
Ref: orders.user_id > users.id

// 方式二：写在字段行内
Table orders {
  id integer [pk]
  user_id integer [ref: > users.id]
}

> 表示多对一（orders 的多个 user_id 指向一个 users.id），- 表示一对一，<> 表示多对多。声明后右侧两张表之间会自动出现连线，端点落在对应字段上。

关系线不显示时，先查这三处：

• 引用的表名或字段名拼写不一致（DBML 区分大小写）。
• ref 写在了表定义之外但表名写错，工具不会报错，只是静默不画线。
• 字段被写在 Table 花括号之外，等于没定义，自然没有连线端点。

调整布局、分组与配色

图变复杂后，可读性靠三件事：

• 分组：用 TableGroup 把相关表圈在一起，例如把 users、orders、order_items 放进 TableGroup ecommerce { ... }，图上会出现一个带标题的边框。
• 配色：在表定义后加 [headercolor: #3498DB] 之类的属性，给表头换色，用来区分模块（如用户域、订单域）。
• 布局：拖拽表的位置，连线会自动跟随。布局调整通常保存在当前图的会话里，刷新后是否保留取决于图是否已保存到你的账户。

导出 SQL、PNG 或分享链接

画完后按用途选出口：

分享链接是这类在线工具最省事的协作方式，评审时对方能直接看到最新结构，不用来回传截图。

常见语法报错排查

DBML 报错通常集中在几类：

• 缺少逗号或括号不匹配：字段属性写在 [] 里，多个属性用逗号分隔，如 [pk, not null]。
• 表名重复：同一张图里不能有两个同名 Table。
• ref 指向不存在的字段：先确认被引用的表和字段都已定义，且拼写一致。
• 注释符号用错：DBML 用 // 单行注释，/* */ 多行注释，用 # 不会生效。

遇到报错时，右侧通常会给出出错行号，从那一行往上检查最近的括号和逗号即可。

什么时候适合用它

如果你的目标是快速把已有或计划中的表结构可视化、导出建表脚本、发给团队看，dbdiagram.io 的文本驱动方式比拖拽式工具更快，改字段只需改一行文本，图自动更新。如果需求是反向工程（从现有数据库自动生成图）或需要严格的数据库方言校验，则要确认工具是否支持你的具体场景，必要时配合其他工具使用。

如果你要的是“写几行文本就能生成数据库关系图，并能导出 SQL”，dbdiagram.io 是上手最快的选择；如果你需要完全离线、或把图嵌入 Markdown 文档，Mermaid 和 PlantUML 更合适；如果你要自由拖拽画布、不介意手动维护，draw.io 更灵活。选哪个取决于你的核心动作是“写 DSL 生成 schema”还是“画图表达结构”。

先明确你要解决的是哪类问题

免费工具之间的差异，本质不在“能不能画 ER 图”，而在下面三件事：

• 图的来源：是从一段文本（DSL / 代码）生成，还是靠鼠标拖拽。
• 输出物：只要一张图，还是要能导出建表 SQL、PNG、PDF。
• 协作方式：个人本地用，还是要分享链接给团队评审、纳入版本控制。

把这三条对上号，选择范围会立刻缩小。

核心差异对比

dbdiagram.io 的定位是“用简单 DSL 快速画数据库关系图和流程”，面向数据分析师和开发者，属于免费工具类别。它的差异点在于：图是从 DSL 生成的，同时这份 DSL 可以反过来产出建表 SQL，这让它不只是画图工具，还参与 schema 设计。

dbdiagram.io 的免费能力边界

从网站资料能确认的是：它是一款免费工具，用 DSL 语言绘制数据库关系图，支持快速生成关系图。关于免费版在私有项目数量、协作人数、导出格式上的具体限制，输入资料未提供细节，因此不做推断——如果你要用于团队私有 schema，建议先在站内确认当前免费额度。

可以确定的使用方式是：

• 用 DSL 描述表和字段，工具据此渲染关系图。
• 面向的典型用户是数据分析师和开发者。
• 支付平台信号显示为 Chargebee，说明存在付费通道，但免费与付费的功能分界需以站内说明为准。

各方案适合谁

选 dbdiagram.io

你的目标是“先写表结构、再出图、顺手拿到 SQL”。适合从零设计数据库模式、需要快速评审表关系的场景。

选 Mermaid

你要把关系图直接写进 Markdown 文档、README 或 Wiki，图随文档一起版本管理，不需要导出 SQL。

选 PlantUML

你要画的不只是 ER 图，还包括更复杂的 UML 关系，且团队已有渲染管线。

选 draw.io

你不追求从文本生成，而是要自由摆放、加注释、画非严格 schema 的示意图，或需要完全离线操作。

选型后第一步：画出并验证第一张图

以 dbdiagram.io 为例，验证流程是：

1. 输入：在 DSL 编辑区写两张有关联的表，例如用户表和订单表，用 Ref 声明外键关系。
2. 动作：工具解析 DSL，在画布上渲染出表、字段和连线。
3. 预期结果：关系图正确显示一对多连线；若语法有误，图不会按预期生成，据此修正 DSL。
4. 导出验证：尝试导出图片或 SQL，确认输出物符合你的下游用途（贴文档 / 建库）。

常见卡点：DSL 里表名或字段名拼写不一致会导致关系线缺失；导出格式是否在免费范围内，需以站内实际按钮为准。

如果第一张图能顺利生成并导出，说明这个工具匹配你的工作流；如果卡在导出或协作限制上，再回到上面的对比表换方案。

dbdiagram.io 适合数据分析师在拿到一批表之后，用一段简单的 DSL 文本把表、字段和主外键写出来，工具会自动生成 ER 图，用于梳理表关系、检查字段缺失、和开发对齐数据模型。前提是你已经知道或能大致推断出表名、字段名和连接键；如果连表结构都还没拿到，需要先向数据源方索取建表语句或字段清单。

为什么数据分析师需要数据库关系图

数据分析师日常面对的是宽表、明细表和维表混在一起的数据源。只看字段列表很难判断：

• 一张订单表的主键是什么，和用户表靠哪个字段连接
• 哪些表是一对多，哪些是多对多，聚合时会不会重复计数
• 某个指标字段到底来自哪张表，是否需要在中间做关联

数据库关系图把这些信息压缩成一张可视化的图，让上述判断从“翻文档猜”变成“看图确认”。dbdiagram.io 的定位就是快速画数据库关系图和流程，面向数据分析师和开发者这类需要频繁沟通表结构的人。

用 DSL 定义表、字段和关系

dbdiagram.io 的核心输入是一段类似下面这样的 DSL 文本。你写表定义，工具渲染成图。

Table users {
  id integer [primary key]
  name varchar
  created_at timestamp
}

Table orders {
  id integer [primary key]
  user_id integer
  amount decimal
  status varchar
}

Ref: orders.user_id > users.id

对应关系是：

输入这段文本后，工具会画出两张表以及它们之间的连接线。预期结果是：你能一眼看到 orders 通过 user_id 指向 users，从而确认“一个用户对应多张订单”这个业务假设是否成立。

用关系线检查连接是否符合业务逻辑

图生成之后，重点不是好不好看，而是关系方向对不对。检查时按这几个问题过一遍：

• 一对多方向：orders.user_id > users.id 表示多张订单属于一个用户。如果画反了，说明你把外键放错了表。
• 多对多：如果两张表之间没有直接外键，而是通过中间表连接，需要把中间表也写出来，否则图上会缺失关键路径。
• 字段缺失：对着图逐个确认分析要用的字段是否都在表里。比如做留存分析时发现 users 表没有注册时间字段，就要回去确认数据源。
• 类型异常：如果 user_id 在一张表里是 integer、在另一张表里是 varchar，连接时可能出问题，图上是能看出来的。

这一步的产出通常是一份“待确认清单”，拿去和开发或数据源方对齐，比直接问“这张表怎么连”效率高得多。

导出和分享给团队做模型评审

图确认无误后，可以直接把图或 DSL 文本分享给团队。评审时大家看的是同一张图，讨论的是具体某条关系线，而不是各自脑补表结构。dbdiagram.io 支持把图导出，也支持通过链接分享，具体导出格式和分享权限以工具当前界面为准。

评审时建议带上 DSL 文本一起，因为图是渲染结果，文本才是可版本管理的源文件。把 DSL 存进项目仓库，下次表结构变更时改文本、重新生成图即可。

常见卡点

• 字段类型写错：DSL 里的类型只是标注，不影响图的关系线，但写错会让评审时产生误解，建议和真实建表语句保持一致。
• 关系方向反了：记住 > 是“多对一”，A.x > B.y 表示 A 的 x 字段指向 B 的 y 字段，A 是多的一方。
• 图太乱：表一多，连线会交叉。可以按业务域拆成多张图，或者把不相关的表先注释掉，只保留当前分析需要的部分。
• 没有主键的表：如果某张表确实没有主键，图上不会自动标出唯一标识，需要你手动确认用哪个字段做连接，避免关联时产生重复行。

dbdiagram.io 本身是一个画图工具，它不连接你的数据库、不校验数据，图对不对取决于你写的 DSL 是否反映了真实表结构。把它当成“表结构的可视化草稿”，而不是数据字典的替代品。

数据库关系图是用图形方式描述数据库结构的一张“地图”：它把表（实体）画成方框，把字段（属性）列在方框内，再用连线表示表与表之间的主外键和一对多、多对多等关系。它适合在动手建表之前理清结构，也适合在团队评审、交接和写文档时作为共同参照。如果你只是要快速画出一张能沟通的关系图，用 DSL 文本描述再自动生成图形，通常比拖拽画图更快、更易维护。

数据库关系图和 ER 图是一回事吗

日常语境里两者经常混用，但侧重点略有不同：

实际工作中，很多工具画出来的图同时具备两者特征：方框里是表名和字段，连线两端标注一对多或多对多。你不必纠结叫法，关键是图要能回答“有哪些表、每张表存什么、表之间怎么关联”。

图里通常包含哪些元素

• 实体（表）：一个方框代表一张表，例如 users、orders。
• 属性（字段）：方框内列出列名和类型，例如 id int、email varchar。
• 主键（PK）：唯一标识一行，通常标 PK。
• 外键（FK）：指向另一张表的主键，是关系的落点，通常标 FK。
• 关系与基数：连线表示关联，两端标注基数，如一对多（1:N）、多对多（M:N）、一对一（1:1）。
• 可选性：关系两端是否必须存在，例如一个订单必须属于某个用户，而一个用户可以有零个或多个订单。

多对多关系在物理建模时通常需要一张中间表（关联表）来承载，例如 user_roles 连接 users 和 roles。

常见的三种画法

用 DSL 文本描述后生成

以 dbdiagram.io 为例，它提供一种简单的 DSL 语言，你写表定义和关系，工具渲染成图。适合版本管理，因为文本可以进 Git、可以 diff。

Table users {
  id int [pk]
  email varchar
  created_at timestamp
}

Table orders {
  id int [pk]
  user_id int [ref: > users.id]
  total decimal
}

[ref: > users.id] 表示 orders.user_id 指向 users.id，即一个用户对应多个订单。改文本，图会同步更新。

用可视化工具拖拽

在画布上新建表、加字段、拉连线。上手直观，适合边讨论边改；缺点是结构复杂后手工维护成本高，改动容易漏。

从现有 SQL 反向生成

如果数据库已经存在，可以把建表语句导入支持反向工程的工具，自动生成关系图。适合接手老项目时快速看清现状，再据此补文档。

从零画一张关系图的步骤

1. 列出核心实体：先写业务里最重要的名词，例如用户、订单、商品、支付。
2. 给每张表定字段：至少确定主键；外键先留占位，等关系理清再补。
3. 确定关系与基数：逐对问“一个 A 对应几个 B，一个 B 对应几个 A”，把答案标在连线上。
4. 处理多对多：需要中间表时补上，并给它自己的主键或联合主键。
5. 检查命名一致性：表名、字段名风格统一，外键命名能看出指向，例如 user_id 指向 users。
6. 评审并迭代：拿图对照真实查询和业务规则，发现缺字段或错基数就改。

验证方法很直接：照着图写出建表 SQL，看能否表达出你需要的查询；或者拿几条真实业务问题去图上走一遍，看关系是否够用。

常见误区

• 只画表不标基数：连线没有 1:N 或 M:N，读者无法判断一条记录能对应几条。
• 忽略可选性：不区分“必须关联”和“可以没有”，会导致建表时 NOT NULL 判断错误。
• 命名不统一：同一含义在不同表里叫 user_id、uid、userID，后期维护和联表容易出错。
• 把图当一次性产物：结构改了图没改，文档很快失效。用 DSL 或反向生成能降低同步成本。
• 过早陷入物理细节：概念阶段就纠结索引和分区，反而拖慢关系梳理。

数据库关系图的价值不在画得漂亮，而在于让结构可讨论、可核对、可更新。选一种能跟上你改动节奏的方式，比选功能最多的工具更重要。

数据库设计是把业务需求翻译成一组结构清晰、约束明确、能长期维护的表结构的过程。它的产物通常包括：表、字段、主键、外键、索引，以及一张能说明表间关系的数据库关系图。如果你正准备从零设计一个关系型数据库模式，可以按“需求梳理 → 概念模型 → 逻辑模型 → 物理实现 → 迭代验证”这条路径推进；像 dbdiagram.io 这类工具支持用简单 DSL 语言快速绘制数据库关系图，适合在概念和逻辑阶段反复调整。

数据库设计要解决什么问题

一个设计良好的模式，通常同时满足三件事：

• 准确表达业务：每条业务规则都能在表结构或约束中找到对应位置，而不是只存在于代码或文档里。
• 减少冗余与不一致：同一事实尽量只存一处，避免更新时出现互相矛盾的数据。
• 支撑预期查询：常用查询能通过合理的表结构和索引高效完成，而不是事后靠加缓存补救。

反过来说，字段类型选错、缺少必要索引、表之间出现循环依赖、命名混乱，都是设计阶段没处理干净、后期代价很高的典型问题。

从零设计数据库模式的核心步骤

第一步：梳理需求与实体

先不急着建表，而是把业务描述拆成“名词”和“动词”：

• 名词往往对应实体，例如用户、订单、商品。
• 动词往往对应关系，例如“用户下订单”“订单包含商品”。

这一步的输出可以是一份实体清单，以及每个实体需要记录哪些属性。属性要区分“必须记录”和“以后可能加”，后者不要提前塞进表里。

第二步：画概念模型（ER 图）

把实体和关系画成图，标出关系的基数：

• 一对一：两边各一条记录对应，通常可以合并到同一张表，除非有性能或权限隔离的理由。
• 一对多：在“多”的一方加外键，例如订单表里放用户 ID。
• 多对多：需要一张中间表，例如“订单-商品”关联表，中间表本身也可以带数量、单价等属性。

概念模型阶段只关心“有哪些东西、它们怎么关联”，不纠结字段类型。

第三步：转成逻辑模型（表结构）

把 ER 图落成具体的表，为每张表确定：

• 主键：唯一标识一行。可以用自增整数，也可以用业务上稳定的自然键，取决于是否需要对外暴露、是否可能变更。
• 外键：指向另一张表的主键，用来表达和强制关系。
• 字段与类型：金额用定点小数而非浮点，时间用带时区的时间类型，状态用枚举或受约束的短字符串。
• 约束：非空、唯一、默认值、检查约束，把业务规则尽量下沉到数据库层。

第四步：规范化，再按需反规范化

规范化（通常到第三范式）的目标是消除冗余：每个非主属性只依赖主键，不依赖其他非主属性。这样更新一处即可，不会产生矛盾数据。

但规范化不是终点。当某些查询需要频繁多表连接、影响性能时，可以有意识地反规范化，例如：

• 在订单表冗余一份下单时的商品单价，避免商品改价后历史订单金额被改写。
• 在统计表里预聚合计数，避免每次实时扫描明细。

关键区别在于：规范化是默认，反规范化是带明确理由的例外，并且要写清由谁、在什么时机维护这份冗余。

第五步：物理实现与索引

建表之后，根据实际查询模式加索引：

• 外键列通常需要索引，否则关联查询和级联操作会变慢。
• 高频过滤、排序、连接的列是索引候选。
• 索引不是越多越好，每个索引都会增加写入成本。

第六步：用图表工具迭代

数据库关系图不是一次画完的文档，而是随设计演进的活图。以 dbdiagram.io 为例，它用简单的 DSL 语言描述表和关系，改几行文本就能重绘整张图，适合在需求讨论中快速试错。你可以先用它画出概念模型，确认关系基数无误后，再补上字段类型和约束，最后对照生成的图检查是否遗漏中间表或外键。

常见错误与排查清单

什么时候算设计完成

设计完成的标志不是“表建好了”，而是：业务规则都有对应约束、常用查询有可行执行路径、关系图能让他人看懂、并且你知道哪些地方做了有意的取舍。达到这几点，就可以进入实现和持续迭代阶段。