Web端开源ER图工具横评：三款数据库建模方案解析

做后端开发这些年，我有个特别深的体会：数据库ER图不是“画”出来的，是“理”出来的。手上有张清晰的ER图，评审需求、给新人讲表结构、排查慢查询关联路径，效率能高出一大截。可惜很多人要么直接在命令行里看字段列表，要么打开老旧的桌面画图软件一格格拖动，既费时间又容易失真。这两年我试过不少Web端可用的开源数据库ER图设计工具，今天把真正留下印象的三款拿出来聊聊。这三款覆盖三种完全不同的工作习惯：纯可视化拖拽、从现网数据库逆向生成、用DSL脚本代码化建模。不管你是习惯画图、写SQL，还是搞逻辑模型评审，总有一款能顺手上路。

我不会只扔几个链接完事。我会把每款工具的适用场景、核心操作、容易踩的坑都过一遍，顺带解答一个很多人纠结的问题：Web 端工具到底适不适合做正经的数据库设计？我的结论是：很合适，关键是选对工具、用对方法。下面直接进入正题。

1. 为什么我盯上“Web 端 + 开源”的ER 图工具

1.1 ER 图的价值不是“好看”，而是把关系摆上台面

先说个最基本的判断：ER 图在项目里的地位，不是一张挂在文档中心的装饰图，而是团队对数据模型共识的可视化表达。业务方问你“订单和用户什么关系”，你嘴上说一百遍外键，不如指着一根线说一句“一个用户可以有多个订单”。我在实际项目里还发现，ER 图对很多隐性问题的暴露特别直接：比如两张表字段命名风格差一个街区，比如某个关联字段连索引都没有，再比如三张表之间出现了循环引用，这些在 SQL 文件里看不出来，但摆到图上立刻扎眼。

很多开发者觉得画 ER 图是 DBA 的事，其实后端工程师、架构师、甚至数据产品经理都在用。需求评审的时候画一张主流程 ER 图，大家讨论的就不是“字段够不够”，而是“业务关系到底怎么落”。所以我的观点很明确：ER 图是数据建模的草稿纸，不是完工以后才补的装饰物。既然如此，工具就必须够轻、够快、够灵活。

1.2 为什么坚持选 Web 端和开源方案

桌面端 ER 工具我也用了一大圈，从商用软件到数据库客户端自带的建模器都用过。后来为什么彻底转 Web 端？就三个字：不折腾。桌面端画一半，换台电脑要继续，得重新装环境、配 JDBC 驱动、同步版本；给同事发一份图，得先导出图片再发聊天窗口，修改一版还要重发一次。Web 工具开个浏览器就能用，出图直接分享链接，多人看同一个版本，问题免了一大半。

至于开源，我的理由没那么宏大，主要是三条：第一，没有厂商锁定，数据模型定义可以用文本或通用格式导出来，换工具不至于从头画；第二，可以自托管，涉及敏感业务库的时候，图和数据都不用落到第三方服务器；第三，社区活跃度通常意味着修 Bug 快、格式兼容多，不会出现某个冷门数据库类型没人支持的情况。当然，开源不等于免费，有些项目要自己搭环境、读文档，这正好符合我要讲的主题：怎么选一套真正能长期用的技术路线。

1.3 三款工具背后其实是三种建模流派

光说工具没意思，我想先把方法论串起来。第一类是通用绘图工具，代表作是 diagrams.net（就是大家熟知的 draw.io），它不是专门为数据库设计的，但胜在万物皆可画，团队里画架构图、流程图的人已经在用，顺手画 ER 图完全没门槛。第二类是逆向工程工具，代表是 ChartDB，核心能力是连上现有数据库，把表结构自动读出来排成一张图，专治“接手上古项目”这种头疼事。第三类是代码化建模工具，代表是 dbdiagram.io 和它背后的 DBML，表结构用类似写代码的方式描述，再由工具渲染成图，还能生成 DDL 脚本。

这三条路线没有绝对的优劣，只有合不合适。我见过有的团队从可视化拖拽一路喊累，最后发现用 DSL 改成文本维护之后反而没人改图了；也见过核心架构师坚持要拖拽式，觉得“看到什么就是什么”才踏实。所以这篇文章我会把三种路线都走一遍，把操作路径、适用场景和坑都讲清楚，你根据自己的工作习惯挑就行。

2. draw.io（diagrams.net）：老牌开源绘图工具，顺手到没有学习成本

2.1 先聊通用工具的 ER 图能力边界

如果你问我最快画出 ER 图的方法是什么，我会说：打开 diagrams.net，新建一个空白图，左边面板加一个 Entity Relation 图形库，然后开始拖矩形和连线。这款工具是 Apache 2.0 协议的开源项目，官方版本直接浏览器访问即可用，也支持部署到自己的服务器。因为它本质是通用绘图工具，所以对 ER 图的支持属于“够用但不深入”的水平。

什么意思呢？它能画实体、画属性、画关系连线，也能导出 SVG、PNG、PDF，甚至支持把图嵌入 Markdown 文档或者 GitHub。但它不会主动帮你检查外键约束，不会因为你在两个实体间连了一根线就生成出 JOIN 条件，更不可能自动帮你调整布局。换句话说，它把画图的自由度全部交给你，同时也把维护正确性的责任交给了你。

这就带来一个很实际的问题：用它画 ER 图，必须自己维护表名、字段、关系正确性。适合什么场景呢？一种是项目早期，表结构还没完全定下来，画个草图给团队对齐思路；另一种是画架构上下文图，ER 关系只是整个图的一部分。如果你要的是一份能长期跟随数据库演进的模型文档，那它确实不是最优解，但这不妨碍它成为上手最快的那款工具。

2.2 三步画出第一张实体关系图

我先说操作路径。第一步：打开 diagrams.net 后，左侧面板会有一个“更多图形”按钮，点开后勾选 Entity Relation，这一步很关键，不勾选的话你只能用基础矩形硬凑，画出来的东西没有 ER 符号语义。第二步：从图形库拖一个实体形状（通常是圆角矩形），双击输入表名，然后用它的列结构快速加字段行。这里有个小技巧：实体图形默认支持 3 列结构（列名、类型、键），你可以在右侧“文本”面板调整表格行数，或者直接用编辑框录入多行文本，每一行对应一个字段。

第三步是连接关系。两个实体之间的关联线，我建议用带基数标记的连线：一对一、一对多、多对多在线的两端拖出对应的端点符号。diagrams.net 的 Entity Relation 图形库里预置了关系标记样式，比如 crow‘s foot（乌鸦脚）标记，选完之后,拖动连线的一端去吸附到另一个实体的边缘即可。不要自己手工画“1”和“N”这种文本标签，纯靠文本标记关系，一旦拖动实体位置就会对不上，图会迅速失控。

2.3 从已有数据库批量生成表结构

手动画表毕竟慢。如果你手上已经有现成的 MySQL 或 PostgreSQL 数据库，想快速把表结构变成图，diagrams.net 还有一个“数据库导入”的隐藏功能。位置在菜单里的 Arrange -> Insert -> Advanced -> From Database，它会弹出一个窗口，让你填写 JDBC 连接串、驱动类、用户名密码，然后读取数据库的表和字段，自动生成一批实体矩形。

这里要提醒一下：这个功能需要本地浏览器能直接访问数据库端口，同时要有对应的 JDBC 驱动。对 MySQL 来说，浏览器环境通常已经内置了驱动，但公司网络策略严格、数据库只允许通过跳板机连接的时候，这个功能大概率会失败。我自己的经验是：别在这上面死磕，如果数据库访问受限，直接用导出的建表 SQL 文本手动生成矩形，反而更快。还有一种折中方式：先用命令行把表结构导出成 CSV 或 Markdown 表格，再按字段批量加入图形，效率也不差。

另外要说一个常见误区：diagrams.net 虽然能导入数据库结构，但它本身不会把任意 SQL 文本自动解析成 ER 图。市面上有些工具号称能粘贴建表语句就生成图，那种通常依赖自己的解析器，和 diagrams.net 不是一回事。所以如果你只需要“从 SQL 生成一张简单的 ER 图”，它可用；如果你需要“以后每次改表结构都自动同步图”，那它做不到。

2.4 分享与协作的正确姿势

Web 端工具天生适合分享，diagrams.net 在这块做得很成熟。它支持把文件保存到本地、Google Drive、GitHub、OneDrive 等位置，也可以生成一个短链接，所有人通过浏览器打开同一个图。我自己最喜欢的功能是导出为 SVG：SVG 是矢量格式，可以无损缩放，放进 Wiki 或者设计文档里非常清晰，而且在部分场景下还能继续编辑文字。

如果团队里用 Git 管理文档，还可以把 .drawio 后缀的源文件直接提交进仓库，每次改动都能 diff，谁改了哪根连线、哪个字段一目了然。这个工作流听起来简单，但很多团队没意识到：ER 图的可追溯性和版本管理，重要性不亚于代码本身。这里也给个经验之谈：使用 diagrams.net 时尽量让文件路径、命名保持稳定，因为图之间可以互相引用文件，路径一变，内嵌链接就断了，维护成本很伤人。

3. ChartDB：连上数据库，自动帮你把老项目梳理成一张图

3.1 它是为“现有数据库”而生的逆向工程工具

如果说 diagrams.net 是“从零开始画”，那 ChartDB 就是“从现状开始理”。它是 2024 年左右在社区里火起来的开源项目，核心能力非常聚焦：连上你的数据库，自动读取表、字段、索引、外键关系，然后渲染成一张可交互的 ER 图。对于接手上古项目、数据库文档缺失、或者要针对存量系统做改造的人来说，这东西简直救星。

它支持的数据库类型覆盖了 MySQL、PostgreSQL、SQL Server、MariaDB 等主流关系型数据库，也支持自托管部署。相比 diagrams.net 那个“从数据库导入”的隐藏功能，ChartDB 把这件事做成了主业，所以解析的准确度、界面的流畅度都比通用绘图工具高一个档次。我第一次用它导入一个几十张表的订单系统时，心里想的是：这要是手工画，怕不是要画一下午。

3.2 实操流程：从连接串到完整 ER 图的四步

第一步，准备连接串。ChartDB 通常要求输入标准的数据库连接信息，比如 MySQL 的 host、port、用户名、密码、数据库名。这里我强烈建议用一个只读权限的账号，避免工具连接过程中出现任何写操作风险，哪怕这个工具本身只读取 meta 信息，规范一点总是好的。第二步，输入连接串后它会尝试连接并读取数据库元数据，成功后你会看到所有表和关系被列出来。第三步，选择要导入的表。按我的经验，除非库特别小，否则第一次导入只勾选核心业务表，把用户、订单、商品、库存这类主干表先放进来，关系图会清爽很多。第四步，导入完成后，工具会自动布局并渲染 ER 图，之后你可以手动拖动实体、折叠字段分组，调整到团队能看懂的程度。

这里有一个值得强调的点：ChartDB 自动布局的质量在同类工具里算是好的，它会尽量把有外键关系的表就近摆放。但如果有几十张表互相连接，自动布局还是会出现连线交叉，这时候不要把时间耗在手动摆位上，建议用它的折叠功能把非核心字段收起来，只留主键、外键和关键状态字段。ER 图的目的是让人看懂关系，不是把每个字段都陈列出来。

3.3 哪些场景用它会特别舒服

我最推荐用 ChartDB 的场景有三个。第一个是交接收尾：新接手一个只有代码、没有文档的项目，连上数据库导一张图，整个业务脉络立刻清晰起来，哪个表是主表、哪个表是关联表、有没有诡异的循环引用，全部现形。第二个是数据库评审：比如你要评估老系统能不能加新功能，先把现有表结构摆到图上，再逐条标注影响范围，给老板汇报时有图有真相，说服力完全不同。第三个是模型同步：团队里有人改了一张表结构，直接把最新库重新导入一次，就能看到差异，省去了手动维护图的痛苦。

还得说句公道话，它也有明显的短板：不太适合“从零建模”。如果你想在项目还没建表的时候先设计逻辑模型，ChartDB 没有提供从空白创建一张新表再逐步加关系的正向建模体验，它更多是作为“数据库现状的可视化层”存在。所以最合理的用法是：把 ChartDB 和代码化建模工具搭配起来用，一个新库用代码建模，改到一定程度重新导入 ChartDB 做展示和评审。

3.4 安全与部署的坑，提前帮你踩了

Web 工具连接数据库，最大的隐患就是连接凭据和数据本身的安全。如果用的是在线公开版本，连接串和读取到的表结构都会经过第三方服务器，对敏感业务来说这是不能接受的。所以我的建议是：能自托管就自托管。ChartDB 提供 Docker 镜像，一条命令就能在内部服务器起一套实例，团队成员通过内网访问，连接串不出内网，安全性高很多。

还有一个操作细节：导完图之后，记得及时清理浏览器缓存里的连接信息。有些在线工具会把上一次连接的 host 和用户名带出来，虽然密码字段通常不会明文保存，但为了保险，使用公共电脑时一定要清除站点数据。另外一个常见问题是网络策略，有些数据库只允许应用服务器访问，你本地浏览器直连会被防火墙拦下，此时就不要硬试了，直接在能连库的机器上部署一套自托管实例即可。

4. dbdiagram.io + DBML：把 ER 图画成代码，主干信息全在文本里

4.1 为什么有人宁可写代码，也不愿意拖图形

看到“写代码画 ER 图”，可能有人觉得多此一举。但我可以给你三个实际场景，看看你是不是也遇到过。第一，画图工具里改了字段名，但没人同步更新数据库，时间一长图和库就分叉了；第二，代码评审时可以 review SQL、review 接口，却没法 review 一张图片，导致 ER 图的正确性无人把关；第三，表结构有几百张，每次调整都要在图上拖半天，图形界面反而成了负担。

DBML（Database Markup Language）就是为解决这些问题出现的。它是一种开源的数据建模 DSL，专门描述表、字段、索引、外键关系。dbdiagram.io 是它的官方在线编辑器，左侧写 DSL，右侧实时渲染 ER 图，还能一键生成 PostgreSQL、MySQL、SQL Server 的 DDL 脚本。更重要的是，这份 DSL 是纯文本，你可以放进 Git 仓库，每次改动都能走代码评审，这对我来说价值太大了。

4.2 用 20 行文本定义一个电商最小模型

直接上一个能跑的例子。假设你正在做一个最小版电商系统，定义三张表：用户表、订单表、订单明细表。打开 dbdiagram.io 或者安装 dbml CLI，把下面的内容粘贴进去：

Project shop { database_type: 'PostgreSQL' Note: '电商订单模块示例' } Table users { id int [pk, increment] email varchar [not unique] display_name varchar created_at timestamp [default: `now()`] } Table orders { id int [pk, increment] user_id int [ref: > users.id] status varchar [default: 'pending'] total_amount decimal(10,2) created_at timestamp } Table order_items { id int [pk, increment] order_id int [ref: > orders.id] product_name varchar quantity int price decimal(10,2) }

粘贴之后，右侧会立刻生成一张带连线的 ER 图。表名、字段、主键、自增、默认值、外键关系，全部从文本中解析出来。你可能会注意到我用了[ref: > users.id]来声明外键关系，箭头方向代表“多对一”。这一行是 DBML 里最核心的语法，关系是否清晰，全靠它。

4.3 从模型到建表脚本的完整链路

dbdiagram.io 的导出能力是它的另一个杀手锏。模型定义完成以后，点导出按钮，可以选择目标数据库方言，比如 PostgreSQL 或 MySQL，工具会自动生成对应的 CREATE TABLE 和 ALTER TABLE 语句。这意味着你可以从同一份模型定义出发，为不同数据库生成建表脚本，而且模型就是唯一的事实来源，不会出现“图是一套、SQL 是一套”的分裂。

对团队协作来说，我推荐把 DBML 文件存到仓库里，配合 dbml CLI 在本地做校验和转换。命令行下可以执行类似dbml2sql --dialect mysql schema.dbml -o schema.sql这样的操作，这样每次表结构变更都相当于一次代码提交，有 diff、有评审、有历史记录。我在实际项目里还会在 CI 里加一步：跑一次 CLI 校验，保证 DBML 语法有效；再跑一次生成，直接输出建表脚本给 DBA 审核。整个链路通了之后，会发现“画图”意义上的 ER 图，其实就是模型的副产品，反而没人再手工维护图片了。

4.4 这篇文本也有自己的坑

DBML 语法整体很简单，但有些细节不能掉以轻心。比如字段类型要写数据库支持的完整类型名，decimal(10,2)这类带精度的类型要带括号；默认值如果希望是数据库函数，需要反引号包裹，比如`now()`；索引定义可以写在表内，也可以写在表外，跨表联合索引的写法容易让人困惑，建议看一下官方文档的索引章节。还有一点，dbdiagram.io 在线版的定位其实是 SaaS 工具，开源的是它背后的 DBML 规范和 CLI 工具，所以如果你对保密性要求高，用 CLI 在本地处理文件，别把模型贴上公网。

另外提醒一下团队使用时的流程问题：DBML 开源以后，很多团队喜欢把模型文件命名为schema.dbml放在后端仓库根目录。这是好习惯，但我建议拆分文件。表特别多的时候，一个文件几千行，review 体验会直线下降。按业务域拆成auth.dbml、order.dbml、inventory.dbml，再通过 include 机制组合起来，关系可读性会好很多。

5. 三款工具横向对比与选型建议

5.1 一张表看清差异

画了这么多，不如直接对比一版。我平时给别人做工具选型时常用下面这个表格：

这个表做完，选型的逻辑基本就清楚了：你手头最缺的是什么，就选对应能力最强的那款。如果你只是偶尔画一两次，没必要付出学习 DSL 的成本；如果你要长期维护一套数据模型，纯拖拽工具大概率会把维护变成体力活。

5.2 别把三款工具当成唯一选择

标题说“三款”，但我不希望你误解成数据库 ER 工具的世界里只有这三个。事实上，很多数据库客户端自带 ER 图导出功能，比如某些 GUI 工具里就有“反转义数据库生成 ER 图”的能力；也有一些老牌的桌面工具在特定数据库生态里很强，只是不符合“Web 端可用”这个前提。所以这里的关键不是“哪款工具天下第一”，而是“在 Web 端、开源这两个条件下，哪些工具值得放进工具箱”。

从我个人的习惯来说，三款工具我一直是组合使用的：新项目表结构设计用 DBML，等库建好、数据量起来之后，把最新结构导入 ChartDB 生成可视化版本，给非技术同事讲业务流程时用 diagrams.net 补一张带业务上下文的全局图。这个组合没有过度依赖某一个工具，所以即使其中某个项目停止维护，我手里的模型定义仍然是可迁移的纯文本或标准图表格式。

5.3 给不同角色的选型建议

如果你是后端开发，且项目处于从零开始阶段，我建议直接从 DBML 入手。别怕学语法，那点语法半小时就能掌握，但从 Git 版本管理、代码评审、自动生成 DDL 这些收益来看，非常划算。如果你是 DBA 或数据架构师，经常需要摸清一个陌生库的底细，ChartDB 这种逆向工具一定要备着，能省下大量阅读建表语句的时间。如果你只是一个临时需要画图给产品或领导看的人，那直接 diagrams.net，五分钟拖一张足够清晰的 ER 图，把核心字段和关系标出来就行，不用理解什么 DSL、连接串、自动布局。

有一点特别想强调：选工具不要跟风。别人说 A 工具好用，可能是因为他的场景是接老项目；别人说 B 工具好用，可能是因为他在做新系统建模。你先明确自己的痛点，再回头看这张对比表，答案不会跑偏。

6. 常见问题与排查技巧实录

6.1 diagrams.net 导入数据库失败，怎么办

最常见的原因是网络访问问题，浏览器所在机器连不上数据库端口。这种情况下先测试一下本地能否通过命令行或客户端连接库，如果本地不能直连，那在线工具更连不上。还有一种情况是 JDBC 驱动缺失，尤其是一些小众数据库分支。我的建议是：不要在这个功能上投入太多时间，它不是 diagrams.net 的主线能力，手动画表结构反而更快；如果表格实在多，就借助脚本把字段批量生成成文本，再粘贴进图里。

6.2 ChartDB 导入几百张表后布局一团乱

大库导入后布局乱，几乎是必然的。我试过导入一个几十张表的库，图面上线交叉得像蜘蛛网。这时候别手动一个个拖，先找到自动布局/自动整理按钮，让它重新排一次；然后把业务上不重要的表隐藏或删除，比如日志表、临时表；最后再手动微调主链路上的几张表。另外，如果几张表之间的连接关系本身太多，也要怀疑下外键设计是否合理，ER 图乱象背后往往藏着真实的设计问题。

6.3 dbdiagram.io 导出的 SQL 在某个数据库上执行报错

DBML 生成的 SQL 是模板化输出，它假设你的数据库是标准配置。遇到报错，先检查字段类型是否用的是目标数据库方言：比如int在 MySQL 上没问题，但某些库里可能希望是integer；varchar要确认长度，很多 DBML 示例不写长度会生成默认值。还有默认值函数，比如now()在 PostgreSQL 里合法，在 MySQL 里写法可能是CURRENT_TIMESTAMP，这类差异只能靠执行前 review 来解决。我通常会在 CI 里把生成的 SQL 拿出来直接跑一遍目标库的测试实例，提前暴露语法问题。

6.4 用在线 Web 工具画 ER 图，数据安全怎么把控

敏感业务数据最怕上公网。我的原则很简单：凡是涉及生产库表结构的，一律用自托管版本或者纯本地 CLI 工具处理；只有脱敏后的模拟模型，才放上在线版做展示和协作。数据库连接串在配置时要遵守最小权限原则，连接账号只给只读权限，并且定期更换密码。自托管部署时，最好把服务放在内网，不对外暴露公网端口。这点上，三款工具里有自托管能力的都建议优先用自托管，别图省事。

6.5 图做完了，怎么保证它不“过期”

很多人的 ER 图画完就变一次性文档，三个月后表结构改得面目全非，图还是老样子。我见过最有效的做法是把“生成 ER 图”这一步变成自动化动作：DBML 模型进 Git 以后，表结构变更必须修改 DBML 文件再提交；然后通过 CLI 再生成一版可视化图，把新图自动发布到内部文档站点。这样每次代码合并，文档也跟着更新，ER 图永远反映最新结构，团队成员不会再拿着一份过期图表做决策。

关于这个问题，我还想补充一句：与其依赖工具自动同步，不如从流程上规定“先改模型，再改库”。把 DBML 文件视作数据库结构的唯一事实来源，库表变更先走模型变更再生成 SQL，这样图和库天然一致。这个流程一旦跑顺，你会发现自己比之前省去大量返工时间。

6.6 团队协作中，ER 图应该由谁来维护

最后聊一个很现实的问题：一张 ER 图，到底该归谁管？我在不同团队见过两种极端：一种是谁都不管，图烂在文档中心；另一种是 DBA 一人维护，其他人只读。我的建议是，把维护职责落到“离表结构最近的那个人”身上，谁改了表结构，谁同步更新对应的模型描述（DBML 或图源文件），并在提交记录里关联说明。代码评审时，顺便 review 一下模型变更，成本很低。团队约定好之后，你会发现 ER 图的维护不再是某个人的负担，而是一套顺手的工作习惯。

我自己现在每隔一段时间，都会把正在做的项目模型重新导入 ChartDB 看一眼全局，确认有没有被忽略的冗余关系。这个过程与其说是“维护文档”，不如说是一次低成本的数据模型体检。工具本身没多神奇，但坚持用工具把结构梳理清楚，确实能少踩不少坑。如果你还在为找不到合适的 ER 图工具发愁，不妨按今天说的方法挑一款先跑起来，画完第一张图你就知道值不值了。