数据库设计这件事基本绕不开 ER 图。尤其这几年课程设计要交 ER 图答辩要讲 ER 图工作中梳理老项目更是离不开 ER 图。但一提起画图工具很多人下意识就是装桌面软件结果要么收费、要么安装繁琐、要么换个电脑就得重新适配环境。我现在的习惯是先看 Web 端可用、开源、能直接在浏览器里打开就干活的 ER 图设计工具有现成的就用现成的没必要为一个画图功能折腾半天环境。今天想分享的就是我最近几个月实际用过、在不同场景下都跑过一遍的 3 款 Web 端开源数据库 ER 图设计工具。如果你正面临画 ER 图不知道选什么工具想从已有数据库快速生成 ER 图多个同学协作画一个数据库设计图这类问题这篇文章应该能帮你少走不少弯路。1. 为什么我盯上了Web 端 开源的 ER 图工具1.1 画 ER 图这个场景到底要解决什么问题先说个我自己的观察。很多人在找 ER 图工具的时候只想着能画出方框和连线忽略了 ER 图真正的用途是梳理实体、属性和关系并且最终要能落到数据库设计上。也就是说一个合格的 ER 图工具应该至少覆盖三件事把你脑子里的表结构变成可视化的图形分清楚主键、外键、唯一约束这些关键信息。能在图形和建表 SQL之间建立双向通道要么从已有数据库结构生成图要么从图导出可执行的 DDL 脚本。支持迭代修改。数据库设计很少一次定型评审完要改字段、加索引、调整关系工具得接得住这种高频改动。按这套标准去看市面上的工具你会发现很多热门推荐其实只满足第一条后两条做得很差。而 Web 端工具天然有个优势打开浏览器就能用改完的图自动存在某个地方或者导出一份文件就能共享不太需要处理安装、升级、跨平台这些破事。1.2 桌面端工具的实际痛点我必须承认桌面端 ER 图工具里有不少功能很强大的比如某些商业软件建模能力确实没得说。但落到实际使用场景问题也很明显安装成本Windows、macOS、Linux 各来一套安装包公司电脑如果权限受限装个软件都要走审批流程好不容易装完发现版本太老还得折腾升级。授权风险很多好用的数据库建模工具是商业授权个人用尚可公司商业项目里用就得掂量 License 够不够合规。协作困难本地文件传来传去Excel 都能把人头搞大更别说一份 ER 图文件被三个人改出三个版本。版本管理麻烦不少桌面工具的工程文件是二进制格式想放进 Git 里做 diff 根本不现实最后只能靠截图对比。所以我不是说桌面端工具不行而是在快速、免费、能协作、不折腾环境这几个条件同时存在时Web 端开源方案几乎是唯一解。1.3 我筛选工具的 4 个标准在测试了 N 多款工具之后我给自己定了几个筛选标准顺便分享出来你找工具的时候也可以参考Web 端可直接访问或者部署足够轻量。在线版打开就能用自托管版至少要支持 Docker 一键拉起不能要求我为了画个 ER 图去手动配 Java 环境。开源或核心功能免费。我不排斥商业软件但既然有开源方案能满足 80% 需求就没必要让钱和授权变成拦路虎。能在图和 SQL 之间转换。反向可以从已有数据库导入生成 ER 图正向可以导出建表语句至少占一头。上手成本低社区/文档能跟上。作为工具不应该让用户反复琢磨怎么用而是打开就会、遇到问题搜得到答案。带着这个标准我最终筛选出了三款分别对应不同的典型场景下面逐个说。2. 三款工具逐个看定位、上手方式与核心玩法2.1 diagrams.net它不是数据库专用却是最听话的 ER 图画板第一款是 diagrams.net也就是很多人熟悉的 draw.io。虽然它不是专门为数据库设计的建模工具但在我推荐清单里永远排第一因为它的通用性和开放程度实在太强。先说开源和部署。项目源码在 GitHub 上对外开放License 是 Apache 2.0这意味着不管是个人用还是商用基本没有授权顾虑。使用方式也灵活直接用官网在线版或者下载桌面端甚至可以下载源码部署到公司内网。我之前给一个数据不能出内网的项目组推荐的就是自托管版本一条 Docker 命令就能起服务整个团队在浏览器里访问数据全程留在内网合规问题也解决了。作为 ER 图画板diagrams.net 的正确打开方式是新建空白图命名为你的项目名。打开左下角 更多形状会弹出形状库管理面板。在搜索框输入Database勾选加载数据库相关的形状库。左侧会出现 Table、Entity、Relationship 等形状直接拖到画布上就能用。Table 形状双击之后可以像编辑表格一样录入字段名、字段类型、主键标记。然后脑补一下这是实体用右侧的属性面板调整颜色、字体、边框。关系线用画布顶部的连线工具从主键字段拖到外键字段线会自动带上端点样式一眼就能看出谁是一端、谁是多端。这个工具最大的特点是什么画出来的图本质上是一份 XML 文件扩展名是 .drawio底层就是结构化文本。这意味着你可以把 ER 图文件直接提交到 Git 仓库每次修改都能做 diff评审时能清楚地看到上次删了哪个字段、这次改了哪条关系线。这一点是很多专业建模工具都做不到的。不过要泼一盆冷水diagrams.net 本身并不擅长自动理解你的数据库结构它的数据库导入功能需要额外配置 JDBC 驱动早年版本在菜单里还能找到入口现在藏得比较深配置成本也高。我实测下来与其折腾导入不如把它当做一个很听话的画板你从 DBeaver、Navicat 或者查询工具里查出表结构然后在画布上手动建模。对几十张表以内的项目来说这个工作量完全可以接受而且手动梳理的过程反而能帮你更深入地理解业务关系。2.2 WWW SQL Designer打开网页就能画的轻量级 ER 图设计器第二款是老牌的 WWW SQL DesignerGitHub 上的项目地址是 ondras/wwwsqldesigner。它是我见过极少数真正纯前端的 ER 图设计工具源码下载到本地直接打开 load.html 就能在浏览器里运行不需要后端服务不需要数据库连接甚至断网都能用。这玩意的使用体验和现代云产品完全不同。界面左边是一块桌面上面放着默认的示例表右边是画出的大画布。你把左侧的表拖到画布上双击表就能编辑字段支持设置字段名、数据类型、主键、外键、默认值、索引等。右侧属性栏还可以调整表名、注释和引擎类型。它的核心亮点落在两点多数据库方言导出和XML 模型持久化。导出 SQL 的时候可以选择 MySQL、PostgreSQL、Oracle、MSSQL、SQLite 等语法切换数据库方言只影响生成 DDL 时的类型映射和语法细节非常实用。模型文件也是 XML 格式保存后在另一台电脑打开接着画即可。操作路径大概是这样的把一张表从左侧桌面拖到画布。双击表在弹出的编辑窗口中填写表名。逐个添加字段选中字段后设置是否主键、是否自增、数据类型。添加外键关系先在子表字段设置外键目标表然后在画布上从主表的主键拖线到子表的外键字段。全部画完后点击导出 SQL选择目标数据库类型复制生成的建表脚本。我实际用下来WWW SQL Designer 的优点是极致的轻量和零依赖适合应急场景。比如你在学校机房、临时电脑上没有安装任何数据库工具又想快速画一张课程设计的 ER 图打开网页就是干。缺点也很明显界面是十几年前的设计风格交互逻辑比较原始没有自动布局也没有协作能力。所以我对它的定位很明确个人轻量建模、离线环境、快速出图。团队多人操作就别指望它了。还要提醒一点它的导入功能比较挑食想直接粘贴一段建表 SQL 让它反向生成 ER 图是可以尝试的但对 SQL 格式要求比较严格表名和字段名必须规范和统一遇到写了奇怪引号或注释的脚本容易解析失败。真碰上复杂库别硬刚老老实实手动建模更省时间。2.3 ERD Online面向团队在线协作的国产开源方案第三款是 ERD Online算是我近期挖掘到的惊喜。它和前面两款有本质差异diagrams.net 是通用画板WWW SQL Designer 更像数字工具而 ERD Online 是专门为数据库建模设计的在线平台主打团队协作和从库到图的整条链路。先说开源情况。这个项目在 Gitee 和 GitHub 上都有开源版本官方也提供在线 SaaS 服务。如果你不想自己部署注册账号就能直接用在线版如果数据敏感或者想深度定制可以拉取开源代码部署到自己的服务器。部署方式对有一定运维基础的同学比较友好Docker 单机拉起就能跑文档里也有详细的部署教程。从功能上看ERD Online 解决了我前面说的两个关键问题反向工程支持配置数据库连接连上之后自动读取表结构、字段、索引、外键关系一键生成 ER 图。这个功能对梳理老项目来说是救命级别几百张表如果靠手动画画到怀疑人生。正向工程在 ER 图上修改表结构、关系完成后能生成对应的数据库 DDL 脚本可以直接拿去执行。另外它支持多人在线协作项目成员可以同时打开一份 ER 图进行编辑有权限管理、操作日志这些功能。虽然是国产开源项目但在产品完整度上比前面两款要现代得多界面也更符合当前的主流审美。我实际测试的场景是这样本地一个测试库有 80 多张表我在 ERD Online 里配置了 MySQL 连接点击同步几分钟后 ER 图就生成出来了自动布局虽然不可能像手工调整那么精细但基本关系都能正确识别主外键连线也标注得清清楚楚。对于快速看懂一个陌生库来说这个效率是手工画图完全比不上的。不过它也谈不上完美。第一功能多意味着学习曲线比前两款陡一些刚上手会有一堆菜单要熟悉第二开源版本和 SaaS 版本之间存在一些功能差异部分高级特性可能放在商业版里第三因为是面向团队的在线系统单纯画一张小图有点杀鸡用牛刀。3. 实战走一遍从反向导入到正向建模两个关键场景说再多功能参数不如实际操作一遍。下面我用三个真实的典型场景来对比测试三款工具也方便你按自己的需求对号入座。3.1 场景 A已有数据库想快速生成 ER 图用于分析这个场景是反向工程也是大家最常遇到的需求比如接手一个老项目、分析一个开源系统的表结构。用 ERD Online 最轻松。配置数据库连接的时候填好地址、端口、库名、账号密码选择要同步的表系统会自动读取元数据。我实测 MySQL 80 多张表从配置到生成出来大约三分钟中途不需要人工干预。生成完之后可以在画布上调整布局给重点表加说明然后导出图片放进设计文档里。WWW SQL Designer 也可以走反向流程方式是粘贴建表 SQL。你需要先从数据库里导出表结构脚本然后粘贴到工具的导入窗口让它解析。这个方法对小表和简单结构是可行的但遇到复杂表时各种约束、索引、分隔符会降低解析成功率。我的建议是把它当备选方案不要作为主路径。diagrams.net 在这个场景最吃力。它没有直接的连接数据库生成 ER 图能力唯一可行的操作是用 DBeaver 之类的工具打开数据库生成 ER 图截图然后在 draw.io 里重新画一份。这个方式适合表少、追求排版美观的交付场景不适合表多、要快速分析的情况。对比结论很清晰如果目的是快速读懂已有库首选 ERD Online。3.2 场景 B从零设计一张订单表导出可执行的建表 SQL现在假设我们要设计一个典型的订单模块包含用户、商品、订单、订单明细这几张表需要正向建模。用 WWW SQL Designer操作起来很干脆。拖四张表到画布上分别为每张表添加主键字段、业务字段、外键字段。表之间连上关系线用户表主键关联订单表的 user_id商品表主键关联订单明细表的 product_id订单表主键关联订单明细表的 order_id。全部连线之后点击导出 SQL选择 MySQL 语法工具会生成类似这样的 DDLCREATE TABLE order ( id INT NOT NULL AUTO_INCREMENT, user_id INT, total_amount DECIMAL(10,2), status VARCHAR(20), created_at DATETIME, PRIMARY KEY (id) ) ENGINEInnoDB; CREATE TABLE order_item ( id INT NOT NULL AUTO_INCREMENT, order_id INT, product_id INT, quantity INT, price DECIMAL(10,2), PRIMARY KEY (id) ) ENGINEInnoDB;当然生成完不等于能直接执行需要根据目标数据库手动补充字符集、外键约束、索引这些细节。这个后面讲坑的时候细说。用 ERD Online 做正向建模体验则是设计器模式。先在项目里新建一个模型然后添加实体字段、类型、约束全部可视化配置。画好之后执行生成 SQL系统会帮你在底层拼出建表语句。它的优势是后续改模型的时候SQL 能保持同步不太容易出现图改了一版、SQL 还是旧的这种错位。diagrams.net 在这个场景下就真的只是画图了。它导出的只能是图片或 XML没有直接生成 DDL 的能力。你需要拿着画好的图手动去数据库里建表。所以我的建议是如果是正经要做数据库设计、后续还要持续迭代别用纯画板工具上专门的设计工具。3.3 场景 C课程设计 / 小组作业多人一起改 ER 图课程设计或者团队项目里经常需要几个人同时完善一份数据库设计图。这时候工具的协作能力就很重要。ERD Online 是这里面协作体验最好的自带团队空间和权限管理成员进来以后大家一起编辑同一张模型图互相看到最新改动。这个模式很接近在线文档协作对小组作业非常友好。diagrams.net 的 Web 版也支持多人实时协作它底层的实时协作能力是有的只要几个人共享同一个文件链接就能同时编辑。不过它的协作是同一份文件概念对权限、项目分区这些没有太多概念适合几个人快速碰一下不适合大规模团队分级管理。WWW SQL Designer 基本没有协作能力只能在单机环境下用多人协作需要导出 XML 文件传来传去不仅效率低还容易覆盖。这属于它的明显短板。表格对比一下工具部署方式数据库反向导入正向导出 SQL多人协作上手成本最适合的场景diagrams.net在线版 / 自托管 / 桌面端弱需要额外配置驱动不支持纯画板支持实时协同编辑极低快速出图、方案汇报、交付文档WWW SQL Designer纯前端打开即用一般粘贴SQL格式要求严支持多种方言DDL不支持低个人轻量建模、离线环境、作业ERD Online在线SaaS / 开源自托管强直接连库同步支持可视化转DDL强团队空间权限中团队协作、老项目梳理、系统建模4. 选型建议不同需求别纠结直接选定位匹配的看了上面的对比你可能已经有了初步判断但也有读者会问那我到底该用哪一款我给几个比较明确的选型建议按场景对号入座即可。4.1 一个人快速画图、出方案、做汇报用 diagrams.net如果你要画的 ER 图主要用于方案展示、设计评审、或者写文档配图那么 diagrams.net 最合适。它的颜值和自由度高可以精细控制每个方框、每条线的样式最终导出的图片直接放进 PPT 里非常专业。最重要的是几乎没有学习成本打开浏览器拖一拖就会了。这种情况下你不需要一个完整的建模平台你需要的是一个随心所欲的画板。4.2 学生党、离线环境、只是为了完成作业用 WWW SQL Designer课程设计、数据库作业、答辩准备这类场景往往不会涉及特别复杂的表结构但对零成本、快速、能用的要求很高。WWW SQL Designer 打开即用、不用注册、不用联网导出建表 SQL 也基本够用非常适合应急。老师要是抽查你的设计过程XML 文件也能证明你是从概念模型一步步设计出来的而不是网上随便截的图。4.3 团队在线设计、长期维护模型、梳理老项目用 ERD Online如果你的项目有几十张表甚至上百张表并且需要多人持续维护数据库设计文档直接上 ERD Online。它的反向同步和正向生成链路非常完整配合权限管理和操作日志能当作团队的数据库建模基础设施来用。我甚至建议把它纳入项目交接的必备文档体系新人入职后看 ER 图比翻建表 SQL 高效得多。4.4 关于工具越多越好的一点提醒很多人容易陷入一个误区觉得工具功能越全越好于是把所有希望寄托在一款全能工具上。但实际用下来我的感受是ER 图工具的核心竞争力是匹配你的使用频率和使用场景。偶尔画一张图的人用一个配置复杂的平台反而会降低效率天天建模的人用一个纯画板工具也会因为缺少导入导出能力而抓狂。先想清楚你要解决什么问题再选工具比装一堆工具再慢慢适应要靠谱得多。5. 实测下来最值得记住的几个坑与提效技巧5.1 坑 1导出 SQL 没有指定字符集中文注释和内容乱码这是我在用 WWW SQL Designer 和 ERD Online 导出 MySQL 脚本时常遇到的问题。工具生成的建表语句默认可能不带DEFAULT CHARSET或者带了但用的是早期版本习惯的latin1结果表建好之后插入中文直接变问号。解决办法不复杂拿到导出的 SQL 后先全局搜索CREATE TABLE在每个表定义后面检查并补充DEFAULT CHARSETutf8mb4同时把ENGINEInnoDB一并确认好。如果你用的是 ERD Online先在模型设置里把默认字符集配置成utf8mb4再生成 SQL能省不少事。5.2 坑 2画了关系线但生成的 SQL 里没有外键约束很多轻量工具把关系线和外键约束是分开处理的。你在画布上连了一条线它只是视觉上的关联导出 SQL 时不一定会在子表里生成FOREIGN KEY语句。我就遇到过画了一堆关系线最后建出来的表一个外键都没有的尴尬情况。所以导出 SQL 之后一定要检查子表的建表语句里是否包含外键约束。如果发现没有建议在导出的脚本里手动为关系线对应的字段补充外键定义。虽然很多生产环境为了性能会避免使用真正的外键约束但课程设计、文档评审这些场景老师一般会要求约束齐全。5.3 坑 3多人协作时文件覆盖冲突更隐蔽用 diagrams.net 的共享协作功能时如果几个人同时编辑同一个文件实时协作一般没问题。但最怕的是导出文件再互相传这种土办法一个人改完导出另一个人在自己的旧版本上改然后再覆盖回去改动的部分就可能悄悄丢了。遇到这种情况把 .drawio 文件放进 Git 仓库管理比用任何文件同步工具都稳妥。因为 .drawio 本质是 XMLGit 能清楚地告诉你每次改动改了什么。ERD Online 这类平台系统本身有操作日志冲突问题会少很多。5.4 提效技巧 1ER 图也当代码来管理文本 diff 非常好用前面提到 .drawio 和 WWW SQL Designer 的模型文件都是 XML 格式这是一个被很多人忽略的巨大优势。我现在的习惯是每完成一版 ER 图设计就提交一次 Git。评审会上如果对某个字段有争议直接打开 Git diff 查看改动说话都更有底气。你不需要专门用什么复杂的建模工具文本格式本身就自带版本管理属性。5.5 提效技巧 2交付用图片协作用在线链接存档用 XML这是我在多次项目交付中总结的处理方式。最终提交文档或 PPT 时用工具的导出功能输出 PNG 或 SVG图片清晰并且不会因为接收方缺少工具而打不开。在团队内部协作讨论时优先使用 Web 端工具的共享链接确保每个人看的是最新版本。所有阶段性成果额外保存一份 XML/SQL 存档到项目仓库里作为设计演进的证据。三个文件各司其职可以避免拿图当档拿链接当交付物的混乱。工具终究只是把想法变成图纸的手段。我见过太多人收藏了一堆工具真到用的时候还是打开系统自带的画图板硬画。希望这篇文章能帮你省下挑选工具的时间把精力更多地放在梳理清楚表结构、关系和业务约束这些更值得投入的事情上。如果你在自己的项目里遇到这篇文章没提到的特殊场景也完全可以在这三款之外继续探索毕竟开源生态里好东西从来不缺缺的往往只是动手试一下的耐心。