开源Web ER图工具横评：draw.io、WWW SQL Designer与CloudBeaver实战

做数据库课程设计的时候，最折磨人的往往不是 SQL 语句怎么写，而是那张 ER 图怎么画。学校老师要求提交逻辑模型图，答辩时要能讲清楚实体和关系；公司里做新项目，也要先在库里把表结构理顺，画出一张能沟通的底图。我自己经历过几个阶段：最早用桌面端绘图软件，装完还要找激活；后来试过在线商业工具，免费版限制多，涉及公司内部表结构又不敢乱传；最后把目光放在开源的 Web 工具上，才发现这个方向其实已经被解决得很好了。

这篇文章就围绕数据库设计里最常用的 ER 图画图场景，介绍 3 款真正能在浏览器里跑起来的开源工具：draw.io、WWW SQL Designer 和 CloudBeaver。它们覆盖三条完全不同的路线——正向设计、SQL 生成、逆向可视化。适合做课程设计的学生、需要快速梳理老项目表结构的后端开发，以及想在团队里统一建模流程的技术负责人。

1. 为什么画 ER 图这件事，值得从桌面软件搬到浏览器里

先想清楚一个问题：ER 图本质上是 "数据库结构设计的中间产物"，它不像代码那样需要 IDE 的深度集成，也不像压测脚本那样对本地环境有要求。它需要的是随时改、随时看、随时给别人留评论。这个特性天然和浏览器匹配。

1.1 需求场景比想象中广泛得多

搜索数据库工具相关话题的时候，能发现一个很有意思的现象：问 "er图用什么软件画" 的人里，至少有一半不是专业 DBA，而是正在做数据库课程设计的学生。他们通常会查 "er图转化为关系模型"、"mysql的表导出er关系图"，核心诉求是快速出图、符合教材规范、能在论文里放得清楚。

而另一类需求来自已经上线的老项目。很多小公司连数据库设计文档都没有，库表几十张，外键关系错综复杂，接手的开发只能一边查 information_schema 一边手动画图。这时"能自动生成关系图"的价值就远大于"手动画得漂亮"。

第三类是协作场景。课程设计的团队里，有人画图有人写代码，如果画图的工具只能保存在本地，其他成员就永远看不到最新版。Web 工具天然解决了这个问题——发个链接或者用共享存储，大家看到的就是同一份。

1.2 桌面软件的三个痛点

桌面端绘图软件在 ER 图场景下有三个绕不开的问题。

第一是安装成本。Visio 这种商业软件要授权，破解版有安全风险；DataGrip 虽然自带 ER 图功能，但那是 IDE 的付费功能之一。为了画一张图装一堆软件，怎么想都不划算。

第二是跨平台协作。团队里有人用 Windows，有人用 macOS，还有人用 Linux，桌面软件的分发、版本管理都是额外工作量。哪怕只是换个电脑，原来存的绘图文件也不一定打得开。

第三是导出和嵌入不方便。论文、PPT、在线文档才是 ER 图的最终去处。桌面软件导出的图片格式经常要反复调整缩放比例，稍不注意导出分辨率就糊了。Web 工具导出的 SVG 可以无损缩放，这对于文档排版是非常友好的体验。

1.3 开源自托管的独特价值

"开源"和"Web"这两个属性叠加在一起，解决了一个在线 SaaS 工具很难解决的问题：数据可控。

如果你只是画一张不敏感的教学图，哪个在线工具都无所谓。但如果要画的是公司核心业务库，表名、字段名本身就暴露了业务逻辑，这时候把结构传到第三方平台心里多少有点不踏实。开源工具可以部署在内网服务器上，数据完全自控，该有的 Web 功能一个不少，还能复用现有的 Nginx、LDAP 等基础设施。

对个人开发者来说，自托管其实也是一件"一劳永逸"的事。一台最低配的小主机就够跑这些工具，一次部署，之后任何设备浏览器打开就能画图。相比反复安装桌面客户端的体验，完全是两种工作流。

2. draw.io：通用绘图工具里最接近专业 ER 设计的那一个

先说第一款，也是大家听过得最多的：draw.io，项目现在叫 diagrams.net。它的定位是通用绘图工具，但很多人并不知道它对数据库设计做了专门支持，甚至可以直接从 SQL 建表语句生成 ER 图。

2.1 部署方式：在线版与 Docker 自托管

draw.io 的 Web 版可以直接打开官方站点使用，不需要注册，画完保存到本地或云端网盘。如果不希望图数据经过第三方服务，官方提供了 Docker 镜像，一条命令就能自托管：

docker run -it --rm --name drawio -p 8080:8080 -v /path/to/draw:/root/.drawio jgraph/drawio

这条命令把容器的 8080 端口映射到宿主机，同时挂载了一个本地目录存图。启动之后浏览器访问服务器的 8080 端口就能看到完整编辑器，体验和在线版基本一致。自托管版同样支持保存到本地磁盘、浏览器、网盘，也可以接 GitHub、GitLab 等外部存储。

这里有个细节值得注意：draw.io 的"数据库建模"能力并不依赖于外部插件，它就内置在编辑器里。官方为它准备了一套 Database 图形库，里面包含表、字段、主键、索引等基础形状，画出来的 ER 图风格非常标准。

2.2 用 DDL 文本快速生成 ER 图

draw.io 最让我觉得惊艳的功能，是能从一段建表 SQL 直接生成 ER 图。它的菜单位置是Arrange > Insert > Advanced > SQL。点击之后会弹出一个对话框，把 MySQL 或 PostgreSQL 风格的建表语句粘进去，点击插入，编辑器会自动解析表名、字段、主键、外键，并绘制成带关系的实体框。

举个例子，粘入下面这段简单的 DDL：

CREATE TABLE student ( id INT PRIMARY KEY, name VARCHAR(50), class_id INT, FOREIGN KEY (class_id) REFERENCES class(id) ); CREATE TABLE class ( id INT PRIMARY KEY, name VARCHAR(50) );

draw.io 会自动生成两个表框，并在class_id和class.id之间拉出一条关系线。表与表之间的连线通过外键识别，方向也比较直观。

这个功能在处理几十张表的结构时尤其高效。手动画一张表要拖拽十几次，用导入的方式只需要准备一份建表语句，几秒钟就能得到一张完整的关系图底稿。之后你可以微调布局、补充分组色块、加注释，最终导出的图既清晰又规范。

需要提醒的是，draw.io 对 DDL 的解析依赖相对标准的语法格式。如果你的建表语句里充满了数据库特有的方言、特殊注释，或者外键定义方式非常规，解析出来的关系线可能会出现偏差。所以正确做法是：先用规范的 SQL 生成底稿，再对它做人工微调，而不是指望工具一次到位。

2.3 画完图之后：导出、协作与版本管理

对于课程设计和团队文档来说，ER 图画完只是第一步，怎么把图放进论文或分享给同事才是真正的刚需。

draw.io 的导出选项很全。File > Export As里支持 PNG、JPEG、SVG、PDF 等常见格式。做课程设计时推荐导出 SVG，在 Word 或 LaTeX 里放大缩小都保持清晰。如果只是为了快速发到群里看效果，PNG 就够了，画布大小可以手动调整。

协作方面，draw.io 虽然没有实时多人光标这种功能，但因为它支持将图保存到 GitHub、GitLab、OneDrive、Google Drive 等平台，本质上可以借助这些平台的协作机制实现多人编辑。内网部署时，把 mirror 目录放到共享存储上，也能达到多人共同维护图表的效果。

这也引出一个实用经验：用 draw.io 画 ER 图的时候，最好把 DDL 文本和图片放在同一个文档目录里，方便追溯。我见过太多同学图导出得很漂亮，但问他要建表语句时却找不到了，实际上完整的表结构定义才是 ER 图的灵魂。

3. WWW SQL Designer：二十年历史的老牌开源 Web 表结构设计器

如果你想要一款"更专精"的数据库设计工具——专门用来从零设计表、生成 SQL，而不是像 draw.io 那样什么图都能画，那么 WWW SQL Designer 值得了解一下。这个项目从 2003 年启动至今仍在维护，仓库地址在 GitHub 的ondras/wwwsqldesigner，是 PHP 社区里知名度很高的开源 Web 表结构设计器。

3.1 部署：一个 PHP 环境就能跑起来

WWW SQL Designer 的技术栈非常轻，就是传统的 PHP 加 JavaScript。部署方式很简单：准备好一个 PHP 环境，把项目代码 clone 到 Web 根目录，然后通过浏览器访问入口文件。

git clone https://github.com/ondras/wwwsqldesigner.git cd wwwsqldesigner php -S 0.0.0.0:8080

如果本机安装了 PHP 5.6 以上版本，这条命令就能在当前目录起一个临时服务。浏览器打开http://localhost:8080，工具界面就出来了。它的界面风格是典型的 2000 年代 Web 应用：上方一排工具按钮，中间是无限画布，左下角有存储和加载选项。

它的核心价值不在界面美观，而在"轻量"。因为不需要 Node.js、不需要编译、不需要数据库，随便一台能跑 PHP 的机器就能部署，非常适合教学环境。如果你所在的实验室没有多余的服务器，甚至可以用局域网里的一台老电脑跑起来。

3.2 从零设计表并导出 DDL

WWW SQL Designer 的工作流围绕表结构本身展开。双击画布空白处可以创建一个新表，双击表标题可以修改表名；表体内部默认有字段列表，点击添加按钮可以加入新的字段，然后依次编辑字段名、类型、长度、是否允许 NULL、是否为自增主键。

建立外键关系的方式也很直观：工具栏上有一个画关系的按钮，从一个表的字段拖到另一个表的字段，松开鼠标后就会形成外键关联。画布上会用连线把两张表连起来，并且能够识别一对多关系。

完成表结构后，最关键的一步是导出 SQL。左下方工具区可以选择方言，支持 MySQL、PostgreSQL、Oracle、SQLite、MSSQL 等多种形式，选择后点击生成按钮，就会按当前选中的数据库方言把 ER 图转换成建表语句。这意味着你可以先在画布上规划好实体关系，再一键得到 DDL 文件，用数据库客户端执行即可建库。

这个反向流程（图生成 SQL）正好补上了 draw.io 的短板。前面提到 draw.io 能从 SQL 生成图，但反过来从图导出 SQL 并不是它的强项；而 WWW SQL Designer 恰恰是面向"设计完后端写代码"这个正向流程来设计的。

我在实际使用中比较多的一个场景是：给新项目设计人员权限模块。先在这个工具里把 user、role、permission、user_role、role_permission 五张表画出来，确认关系没有遗漏，再导出 MySQL 方言的 SQL，直接放在项目初始化脚本里执行，效率很高。

3.3 老工具的现实局限

说实话，WWW SQL Designer 也明显有它的年代感。界面完全不响应式，在手机上打开基本没法用；画布缩放、对齐辅助、批量改字段等现代建模工具的标配是缺失的；如果表数量超过五十张，画布操作会开始有点卡。

另外，保存和加载设计文件虽然支持导出为本地 XML，但格式是它自己的私有格式，无法直接与其他建模工具互通。它还有一个"从数据库导入已有表结构"的后端能力，但需要额外配置后端存储环境，实际用起来不如 CloudBeaver 那样开箱即用。

所以我给它的定位是：快速原型设计、教学演示、轻量化正向设计。它适合在项目早期把核心实体和关系理清楚，一旦表结构达到几十张以上，就应该换用更专业的工具来做管理。

4. CloudBeaver：把已有数据库反向生成 ER 图的开源 Web 工具

第三款工具和前面两款思路完全不同。CloudBeaver 本质上是开源数据库客户端 DBeaver 的 Web 版本，但是它的 ER 图可视化能力非常强，特别适合"已经有数据库，需要快速生成表关系图"的场景。

4.1 用 Docker 一键起服务

CloudBeaver 的官方仓库在 GitHub 的dbeaver/cloudbeaver，提供 Docker 镜像，部署比想简单得多：

docker run --name cloudbeaver --rm -ti -p 8978:8978 dbeaver/cloudbeaver

启动后浏览器访问服务器的 8978 端口，首次进入会要求创建一个管理员账号，然后就能在管理界面里配置数据库连接。支持 MySQL、PostgreSQL、SQLite、Oracle、SQL Server、ClickHouse 等常见数据库，连接信息的填写方式和 DBeaver 桌面版基本一致。

CloudBeaver 的定位是 Web 端数据库管理客户端，所以除了看 ER 图，它还能执行 SQL、查看表数据、管理权限等。这意味着它就相当于给团队提供了一个统一的数据库管理入口，部署在内网后各成员都不用再各自装桌面客户端了，浏览器打开就能操作。

4.2 连接数据库并生成关系图

连上数据库之后，生成 ER 图非常直接：在左侧数据库树里找到你要可视化的库或模式，右键单击，在菜单里选中 "View ER Diagram"。

CloudBeaver 会自动读取当前库的表、字段、主键、外键和索引信息，以 ER 图的形式展示出来。表与表之间会根据外键关系自动连线，表内字段也会标注主键、可空性等属性。画布支持拖拽调整布局、缩放、选择层级，整体交互比想象中的流畅。

这套机制解决了一个很实际的问题：老项目的表结构文档几乎为零，新接手的人只能靠一条条看建表语句来建立全局认识。用 CloudBeaver 连接一次测试库，把 ER 图导出来，再结合几张核心表的数据样例，对整个数据库结构的理解效率会高上好几倍。

4.3 关系图的保存与分享

CloudBeaver 查看 ER 图之后，可以保存为 PNG、SVG 格式的图片。右键点击画布空白区域，选择导出图片，就能把当前视图存到本地。

有一点需要提醒：CloudBeaver 生成的 ER 图更偏向"数据库结构的真实映射"，它不会像设计工具那样自动做布局美化，也不会把多对多关系自动拆分成中间表。你看到的就是数据库里的实际结构，有些表间如果没有外键关系，即使逻辑上是关联的也不会画出连线。这是它作为逆向工具的特点，不是缺陷。

实际使用中，我一般把 CloudBeaver 生成的图当作"基础底图"，然后导入到 draw.io 里重新整理布局和分组，加上注释后作为正式文档。这个组合方式既保证了结构准确，又兼顾了可读性。

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

三款工具的定位差异很大，但很多人第一次看到时容易混淆。下面这张表把它们的核心区别整理出来，可以直接用来做选型参考。

5.1 三款工具核心参数对比

5.2 不同场景下的选择思路

如果你是在做数据库课程设计，需要画一张规范的 ER 图放进论文里，同时还要把实体关系说清楚，首选 draw.io。从 DDL 生成底稿再手动整理，出图速度快，导出 SVG 放进论文很清晰。如果老师要求提交建表语句，可以用 WWW SQL Designer 把图画完后导出 SQL，或者直接手写 create table 语句维护同目录的一份 DDL。

如果你是后端开发，接手一个没有人维护文档的老项目，重点是搞清楚库里有哪些表、表和表之间怎么关联，CloudBeaver 是最优选。一条 docker 命令起来，连上库右键看 ER 图，几分钟就能建立全貌，还能顺手执行 SQL 验证数据，这个体验是其他工具替代不了的。

如果你是小型团队的技术负责人，希望统一团队的建模方式，我更推荐"双工具组合"：用 CloudBeaver 连接开发库，定期生成结构底图；用 draw.io 维护正式的架构文档，作为评审和交付物。至于新功能涉及的新表设计，可以在 draw.io 里用 DDL 导入快速验证，或者回落到 WWW SQL Designer 做正向建模。

5.3 我自己的固定工作流

这里分享一套我现在经常使用的固定流程：拿到需求后，先在 WWW SQL Designer 里快速画出核心实体和关系，导出初始 DDL；在真实数据库里把表建好、填入样例数据；然后用 CloudBeaver 连接数据库，右键查看 ER 图，核对结构是否和设计一致；最后把 CloudBeaver 导出的图导入 draw.io，整理布局、补充业务说明，形成正式的设计文档。这套流程已经把"设计-实现-核对-文档化"串成了一条完整的链路，每张图都是真实结构的映射，基本不会出现文档和代码不一致的尴尬情况。

6. 画 ER 图时的常见坑与课程设计实战细节

工具用顺手之后，真正决定 ER 图质量的其实是基础理论。很多人在绘图工具里把表拉出来、线连上，图看起来也像模像样，但交给老师或同事一看就露馅。这里说说最常出问题的几个点。

6.1 ER 图转关系模型的通用步骤

搜索热点里经常出现"er图转化为关系模型"这个需求，对应的其实是数据库设计里的标准流程。教材上的做法可以概括为三步：

第一步，把每个实体转换成一张表。实体的属性就是表的字段，实体的主键就是表的主键。这一步看起来简单，但经常有人把多值属性当成一个字段存在表里，比如一个学生有多个联系电话，正确做法是单独建一张联系表，而不是在 student 表里加 phone1、phone2、phone3。

第二步，处理关系。一对一关系可以把任意一方的主键放进另一方做外键；一对多关系在"多"的一方加外键引用"一"的一方的主键；多对多关系必须拆成一张中间表，中间表的主键通常是两个外键的组合，同时这些外键也分别指向两边的主键。

第三步，优化和规范化。检查所有字段是否满足至少第三范式，即非主键字段不能依赖于其他非主键字段。比如把"班级名称"直接存在 student 表里就不太规范，应该通过 class_id 关联班级表。课程设计里如果这一步做得好，老师会很认可。

6.2 我踩过的几个具体坑

工具使用过程中有几个非常具体的坑，遇到了可以先按下面的思路排查。

第一个坑：draw.io 导入 DDL 后外键连线丢失。这通常是因为 DDL 里的外键名重复，或者外键定义被写在了表级约束之外导致解析没识别到。解决办法是给每个外键起全局唯一的约束名，导入前先把超长的注释删掉，尽量使用标准的FOREIGN KEY (col) REFERENCES table(col)语法。

第二个坑：CloudBeaver 里查看一张几十个字段的大表时，ER 图非常乱。这是它照实绘制所有字段的结果，并不是工具故障。解决办法是在画布上手动隐藏不关心的字段，或者调整表的折叠状态，只看主键和外键字段，然后再截图导出。

第三个坑：WWW SQL Designer 导出的 SQL 在中文环境下出现乱码。这个工具诞生年代较早，对 UTF-8 的支持有时会出现问题。解决方法是导出 SQL 后用编辑器转成 UTF-8，或者在生成 DDL 后手动在表定义上加DEFAULT CHARSET=utf8mb4后缀。

6.3 给课程设计和新手的最短可行路线

最后给正在做数据库课程设计的同学一条最短可行路线：先不要急着画图，把需求里的核心实体列出来，控制在 6 到 10 个实体以内，确定每个实体的主键和主要属性；然后用 draw.io 的 SQL 导入功能生成底图，手动调整布局，加上关系线标注；再根据 6.1 提到的规则检查有没有多对多关系没有拆中间表；最后导出 PNG/SVG 放进文档，把对应的 DDL 附在附录里。

只要沿着这条路线走，ER 图部分基本不会成为拉分项。反过来，如果把大量时间浪费在折腾破解软件和反复重画布局上，那才是真的消耗精力。

工具只是辅助，你对数据库结构的理解才是图纸真正的质量。选择开源 Web 工具的初衷，说到底就是把重复劳动交给代码，把思考时间留给自己。这套流程用顺手之后，你会发现在浏览器里设计数据库这件事，远比想象中靠谱。