前阵子给新来的同事讲老项目的数据结构几十张表的关系我在本地画了半天最后把图片发过去对方反问一句订单表和支付表中间是不是少了一张关联表。我又得打开源文件继续改、重新导出、重新发。这种来回折腾的次数多了我彻底改变了对 ER 图工具的认知能挂在 Web 端、能在浏览器里直接打开和协作、最好还是开源可以自部署的才是适合团队长期使用的。后来我把市面上能满足Web端 开源 数据库ER图 设计工具这几个条件的项目都过了一遍真正能拿来干活的我最推荐以下三款。1. 先定个调为什么 ER 图要选 Web 端 开源1.1 传统工具的痛点画 ER 图不是低频操作。每次要做数据库结构评审、写技术文档、给新人讲业务模型都躲不开它。最普遍的做法是打开 Navicat 的逆向表到模型或者用 MySQL Workbench 画 EER 图但这两条路我都踩过坑。Navicat 的模型功能在付费版本里才完整免费版结构一复杂就开始弹限制画到一半被卡住的感觉很糟MySQL Workbench 只服务 MySQL换个 Postgres 项目就得再找工具而且新版界面越来越重低配笔记本打开光渲染模型就要卡几秒。至于 DbSchema 这类专业建模软件功能确实全但落到团队协作里又是另一个问题每个人都要在自己电脑上装同一套软件还要协调许可证、版本号不一致导致的兼容问题。本地工具的劣势在协作场景下会被放大。ER 图文件一旦存在个人电脑里其他人想看就得传文件、装软件、照路径打开链路太长跨部门评审时对方可能根本不关心你的画图软件只想要一张能看懂表长什么样、和谁有关联的图。让所有人打开同一个 URL、或者通过统一的容器服务访问同一个页面显然比到处传文件舒服得多。我后来给团队搭数据库文档体系时就立了一个原则任何一张 ER 图都应该是浏览器里能直接看的而不是某个人的本地文件夹里躺着的私有文件。1.2 我筛选三款工具的标准网上一搜在线 ER 图工具能出来一大堆但大多数要么是闭源 SaaS、数据要传到别人服务器上要么只能试用水印版。我的筛选逻辑很简单必须是开源项目代码能在公开仓库找到许可证允许自己部署甚至内部二次开发必须在浏览器里打开或者可以自部署后通过浏览器访问不依赖某个商业账号数据和文件能自持至少要覆盖从 SQL 生成 ER 图连接数据库查看关系从零设计表结构这三个场景中的一种。按这个标准筛完我留下了三款。第一款是 diagrams.net也就是大家常说的 draw.io定位是通用绘图但支持解析 SQL 建表语句并自动生成实体关系图第二款是 CloudBeaver作为 DBeaver 团队出品的 Web 数据库管理工具连上数据库后可以直接查看表之间的外键关系图第三款是 erd-editor一个纯粹跑在浏览器里的 ER 图编辑器适合从零设计数据库表结构也能一键生成 DDL 建表语句。三款恰好对应三种典型工作流下面一个一个展开。2. diagrams.net一个万能画板也能把 SQL 变成 ER 图2.1 为什么我第一个推荐它diagrams.net 是我用得最久的一款很多人把它当示意图工具用画架构图、时序图、流程图但忽略了它在数据库建模上也能干正事。它底层对表格和关系连线这两种元素有原生支持插入一个表格形状、给列添加属性、用连线连接两列并设置关系这套操作并不依赖专业 ER 工具。更关键的是它内置了一个 SQL 导入功能你把手里的建表 SQL 粘贴进去它能自动识别出表名、字段名、字段类型和外键关系然后把整个 ER 图框架画出来。对已经有一份数据库结构只想快速转成图的场景来说这个入口非常省事。它的开源协议是 Apache 2.0既可以无条件使用官方提供的在线版 draw.io也可以把 release 包下载下来部署到公司内网。我的实际经验是只要项目里用了 MySQL、PostgreSQL 这类常见数据库并且建表脚本里老老实实写了外键约束用它生成 ER 图的准确率相当高不需要额外装插件也不需要写任何代码。对比那些只能靠手动拖图形去堆的工具它的门槛明显低一截。2.2 实操从建表 SQL 到 ER 图的一步步过程我平时最常用的路径是这样走的。第一步先把数据库里的建表脚本导出成一份 SQL 文件。MySQL 项目可以用 mysqldump 加--no-data只导出结构PostgreSQL 项目用 pg_dump 也可以只要保留 CREATE TABLE 和 FOREIGN KEY 相关部分即可。第二步打开 diagrams.net 的在线版或者内网自托管版本新建一张空白图。第三步在顶部菜单找到 Arrange - Insert - Advanced - SQL会弹出一个对话框把建表脚本整段粘贴进去。这里要提醒一下最好只保留结构语句不要混入 INSERT 的数据行否则解析到后面容易出偏差。点击插入之后diagrams.net 会把每一张表生成一个矩形框字段列表显示在框内并根据外键自动拉出连线。刚生成完的图往往很乱因为表之间的连线会交叉字段顺序也不完全符合阅读习惯。我的做法是先不着急拖动盯着图看一分钟理清主表和子表的位置然后执行菜单里的布局工具比如分层布局或者树形布局让整体结构自动排一遍。最后再手动拖几笔把核心业务表放中间、关联表放四周这张图基本就能用了。整个过程如果不算导出的时间十分钟内可以完成。2.3 排版美化与导出的小技巧很多人在画完线之后就交差了但我建议多花两分钟处理可读性。diagrams.net 生成的所有表默认是同一套样式字段一多就分不清业务边界。我会先把每张表标题区域的填充色按业务模块调整一下订单相关的用一种颜色用户相关的用另一种评审会上大家一眼就能跟上思路。具体操作是选中表格形状在右侧格式面板修改 Fill Color然后把它保存成自定义样式后面新插入的表可以直接套用。另一个小技巧是把主键字段加粗外键字段加一个前缀标记虽然 ER 图本身不强制这样但放进文档之后的阅读体验会好很多。导出时我一般先导成 SVG 或 PDF发图给产品、前端、后端的时候用 PNG 也够用。如果想把整套图挂进内部的文档系统或者 Git 仓库更推荐的做法是把 .drawio 源文件直接提交上去之后任何人改动数据库结构只要更新这份文件再重新导出图片即可。这也引出了 diagrams.net 在协作上的一个优势源文件是纯 XML 文本Git 的 diff 能直观看出哪个表被加了字段、哪条关系被删掉了。这一点很多专业建模工具反而做不到。2.4 实际踩过的坑用 diagrams.net 画 ER 图我提醒三个容易踩的坑。第一个它识别外键关系依赖建表语句里的 FOREIGN KEY 约束。如果老项目里很多表是逻辑外键也就是只有同名字段、没有真正在数据库层面声明约束那它不会自动连线需要你自己拉线。遇到这种情况别怀疑工具坏了补上关系线或者提前整理一份外键清单就好。第二个SQL 导入对话框对语法有一定要求MySQL 的 COMMENT 语句、带反引号的字段名、PostgreSQL 里的一些特殊类型偶尔会出现解析偏差。我的对策是只贴核心的 CREATE TABLE 片段不要整份复杂 dump 堆进去准确率能提高不少。第三个坑是关于在线版是否免费的疑问。diagrams.net 和 draw.io 本质上是同一个项目不同分发渠道在线版没有强制商业收费也不用注册账号默认数据保存在浏览器本地如果要长期保存建议随时导出文件别把在线编辑当成云存储用。总之它适合作为随手画、快速分享的选择但如果你需要的是连接数据库实时查看关系它就不是最佳方案了这就顺理成章地引出下一款工具。3. CloudBeaverDBeaver 的 Web 版连上库就能看关系3.1 它到底是个什么工具CloudBeaver 是 DBeaver 团队做的 Web 版本项目开源许可证是 Apache 2.0。DBeaver 在桌面端数据库工具里的口碑不用多说而 CloudBeaver 把核心能力搬到了浏览器里你可以在网页上连接 MySQL、PostgreSQL、ClickHouse、Oracle 等主流数据库浏览表结构、执行 SQL、查看数据顺带查看表与表之间的外键关系图。它的目标不是取代桌面版而是让整个团队不用各自安装客户端打开同一个地址就能管理数据库。这一点非常适合搭建团队内部的数据库浏览入口尤其是后端同学不在、新人又要查表结构的时候。我在这篇讲 ER 图的文章里推荐它是因为它自带 ER Diagram 页签。现在的数据库项目动辄几十张表靠人肉看外键永远看不全CloudBeaver 连上库之后选择一张核心表就能看到它和哪些表产生了关联以及关系线的方向。这个能力对接手旧项目、排查数据关系、给新员工讲解数据模型都很有价值。它不需要你先准备 SQL 文件也不用手动画任何线数据库里已有的结构就是图本身。3.2 用 Docker 一分钟拉起一个实例CloudBeaver 的部署是我用过的同类工具里比较省心的官方提供 Docker 镜像直接跑容器就能启动。我给团队搭测试环境时用的是下面这套 compose 配置version: 3.8 services: cloudbeaver: image: dbeaver/cloudbeaver:latest container_name: cloudbeaver ports: - 8978:8978 volumes: - ./cloudbeaver-data:/opt/cloudbeaver/workspace restart: unless-stopped把上面的内容存成 docker-compose.yml然后在同一目录执行docker compose up -d等服务起来后浏览器访问http://localhost:8978就能看到初始化界面。第一次访问会要求创建管理员账号这个账号只用于管理 CloudBeaver 本身和你真正要连接的数据库账号是两回事。创建完成后左侧边栏找到创建连接选择数据库类型填写主机、端口、数据库名、用户名密码保存即可。整个过程不需要在服务器上额外安装数据库驱动CloudBeaver 会自动处理。有一点需要提醒它是 Java 服务端应用占用内存会比普通静态页面高。在我测试过的机器上单实例空闲时大约占 500MB 左右内存如果还要同时连多个库、开多个会话建议给它留 1GB 以上。对一个小团队来说把这套服务部署在开发机或内网服务器上就够用了不需要大资源投入。3.3 在浏览器里打开 ER 图的路径连接好数据库之后找 ER 图的方式并不难。左侧导航树展开数据库连接再展开目标 Schema里面会出现所有表。任意点击一张表右侧面板会显示这张表的属性信息其中有多个页签包括 Properties、Data、References、ER Diagram 等。切到 ER Diagram 页签CloudBeaver 会把当前表以及通过外键关联到的表一起显示在图形区域里用连线标明关系。如果你想把更多表纳入到一张图里可以回到导航树继续选中其他表或者在图表区域里拖入新的表对象。不同版本的入口名称可能会有一点差异但大方向是一致的。这个 ER 视图的交互方式和桌面版 DBeaver 很接近支持缩放、拖动、选中高亮关系线。不过要说明的是它更适合查看已有关系而不是从零设计表结构——想新增一张表、手动拖一条逻辑关系出来这个工具不擅长还是回到专用的 ER 编辑器更顺手。另外关系图的数据完全来自数据库里的物理外键约束如果库本身没有建外键ER Diagram 页签里自然就是孤零零的几张表。接手那些裸奔老库的时候这个现象很常见。3.4 实际体验中的优劣从我几个月的实际使用感受来看CloudBeaver 的优势很突出。一是界面响应速度在局域网内非常流畅和桌面端差距不大二是它天然支持团队多账号登录可以给前端、测试、运营分配不同的只读账号三是日常的查表、跑 SQL、看 ER 图都在一个浏览器标签页里完成省去频繁切换客户端的烦躁感。劣势也同样明确它的 ER 图功能定位是辅助性的画布自由度不如专用工具关系线自动布局偶尔会交叉想做出能直接放进技术方案文档的精修图还得在外部工具里二次调整。如果你所在团队已经有统一的数据库管理平台那 CloudBeaver 可以当作一个轻量补充如果现在什么都没有又想低成本给团队提供一个浏览器访问数据库 看表关系的入口它的性价比非常突出。一句话总结它是用来读懂已有数据库的利器不是用来创作数据库设计的工具。4. erd-editor一个纯粹为了画 ER 图而生的开源编辑器4.1 最轻量的打开方式前面两款工具一款是通用画板一款是数据库管理平台而 erd-editor 的定位非常纯粹它就是用来画 ER 图的。代码托管在 GitHub用的是 MIT 许可证核心能力包括可视化创建表、编辑字段、建立表间关系以及导入导出。第一次打开这个项目时让我印象最深的是它的运行方式——没有复杂的后端依赖本质上是一个前端应用只需要把项目跑起来浏览器里就能获得完整的编辑画布。你也可以把它打包成静态文件放到公司内网的任意 Web 服务器上所有数据都保存在本地不会上传到任何第三方服务。这对只想安静画一张表结构设计图的人来说很合适。用 diagrams.net 画还得在一堆通用图形元件里找方向用数据库管理平台看图又不能自由修改。erd-editor 把ER 图专属编辑器这件事做到了极致界面上直接就是表、字段、关系线没有多余的干扰项。4.2 从零设计表结构的完整流程我从零设计新库表结构时用的就是它。整体流程大概是这样的。第一步在画布上新建一张表给它一个符合业务语义的表名比如 orders。第二步在表内部添加字段每个字段都可以设置字段名、数据类型、长度、是否主键、是否非空、默认值、注释信息。第三步当两张表之间存在关联时不需要手动输入外键字段名而是从字段后面拖出连线、指向另一张表的字段编辑器会自动生成对应的外键关系。第四步等所有表和关系都画完使用导出功能生成目标数据库的 DDL 脚本比如 MySQL 或 PostgreSQL 的建表语句直接扔到数据库里执行。这里我想多说一句外键关系的处理。很多老项目实际上不建物理外键只保留逻辑关联erd-editor 中你仍然可以把线连出来表达业务上有关联这个语义而在导出 DDL 时可以选择是否需要生成 CONSTRAINT 外键约束。这个灵活性对设计阶段很重要——你可以先关注业务关系具体要不要在数据库层面约束后面再决定。相比某些在线工具一上来就强制生成物理外键这个做法给后续改造留了余地。实际操作中还有几个对帮助很大的细节。左侧的表清单可以当导航目录用表多的时候不用在画布里大海捞针鼠标拖拽表头可以批量移动一组表按住画布空白处拖动是平移视图滚轮缩放没有明显卡顿感。对于一款纯前端工具来说画布交互能做到这个流畅度已经超出预期。字段编辑器里的类型下拉框是预置好的常见类型列表不用手敲也从源头上避免了拼写错误如果切换到 PostgreSQL 类型集合再切回 MySQL编辑器会尽量保留兼容的类型映射。4.3 配合版本管理使用的正确姿势erd-editor 的另一个特点是数据格式可以被版本管理。它把图保存成结构化的 JSON 文件字段、表、关系、样式都在里面。我现在的习惯是每个项目的 docs/db 目录下放一份表结构 JSON同时导出一版 DDL 脚本每次修改表结构先改 erd-editor 里的图再导出 DDL最后把这两个文件一起提交到 Git。这样一来团队里任何一个人都能通过同一份 JSON 打开同一个 ER 图review 时能看到结构变化而不是靠聊天工具里传截图来来回回。不过坦白讲它也有短板。首先它不支持多人实时协作两个人同时编辑同一个文件会互相覆盖所以更适合单人编辑、其他人以查看为主其次它没有内置数据库连接能力不能像 CloudBeaver 那样一键从线上库反向拉取表结构想导入已有库还得借助其他方式先把结构转成它支持的格式。但结合它 MIT 开源、纯前端、轻量的特点这些缺点在设计新表结构、维护数据库文档这个场景里完全可以接受。如果你需要一个专业 ER 图编辑器又不想被商业软件绑定erd-editor 值得放进工具栏。5. 三款工具怎么选按场景、按团队、按协作方式5.1 核心参数对比这三款工具并不是替代关系在不同任务里它们各自有明确的分工。我先用一张表把核心差异列清楚方便你根据团队情况直接选型。维度diagrams.netCloudBeavererd-editor定位通用绘图 SQL 导入Web 数据库管理平台专业 ER 图编辑器部署方式在线版 / 自托管静态站Docker 等自托管纯前端静态部署连接真实数据库不支持支持不支持从零设计表结构可以但偏手动不擅长擅长导入已有库结构生成 ER 图需要先导出 SQL 文件连库后直接查看需借助 JSON 等格式生成建表 DDL部分场景支持不提供 ER 图为主支持多数据库类型多人实时协作一般支持多账号登录不支持源码许可证Apache 2.0Apache 2.0MIT适合场景快速把 SQL 变成一份讲解文档团队统一入口浏览与管理数据库新库表结构设计、文档归档5.2 我的组合使用建议如果你问我到底选哪一款我的答案往往是别只选一个组合起来用。日常最顺手的组合大概是这样的。接手已有项目时先把 CloudBeaver 搭起来连接测试库利用 ER Diagram 快速摸清表关系和字段含义等需要给领导或客户做方案汇报时再从 CloudBeaver 里确认关系用 diagrams.net 画一张美化版 ER 图加入业务分组颜色和文字说明而如果项目还在设计阶段新表结构每天都在变我更喜欢用 erd-editor 完成从设计到 DDL 导出的闭环等结构稳定后再把结果同步到文档里。这个组合的逻辑很简单连库看图要真实所以用 CloudBeaver交付文档要好看所以用 diagrams.net动手设计要灵活所以用 erd-editor。分清楚查看、汇报、设计三种场景它们的定位一点也不冲突反而能做到珠联璧合。5.3 最后一个提醒最后分享一个我在实际项目里踩过坑之后总结出来的习惯ER 图这种交付物最怕画完即弃。很多团队在项目初期吭哧吭哧画了一张大图后面数据库一直改文档却再也没更新过。等三个月后新同事接手看到的还是一张和真实表结构完全对不上的图那比没有更糟糕。所以无论你选哪款工具一定要把 ER 图的源文件纳入版本控制并且约定表结构变更时必须同步更新对应的 ER 图文件。把流程固化下来比工具本身先进更重要。我自己的操作是每次发布涉及数据库变更的需求顺手把新生成的 JSON 或 drawio 文件提交进同一个 MR让评审人在看代码的同时也能看到数据模型的变化。这套习惯坚持下来之后团队里关于这个表到底谁关联谁的疑问明显少了很多。
