数据库ER图怎么画？三款开源Web端ER图设计工具实测对比

要论写数据库项目时最容易被低估的环节画数据库 ER 图绝对排得上号。数据库课程设计要交 ER 图老项目交接要补 ER 图写技术方案得用 ER 图讲清楚表结构连面试聊表设计时面试官都常让你现场画两张表的关系。而我前几年一直用桌面工具画后来工作组里 Windows、macOS、Linux 混着来桌面工具换来换去光是安装、许可证和文件格式就消耗了大量时间。直到我把目光转向 Web 端开源工具才发现在浏览器里也能把 ER 图做得很好用不用装客户端、部署到内网就能给全组用、导出的图片和 SQL 还能直接进文档。这篇文章就说说我实际用过、现在还留在工作流里的 3 款开源 Web 端数据库 ER 图设计工具以及它们各自的适用场景和容易踩的坑。1. 为什么我不再把 ER 图画在桌面工具里1.1 桌面建模工具的隐性成本先说一个很多人没意识到的问题桌面端 ER 图工具不是不好用而是它的隐性成本太高。以我最早用的 PowerDesigner 为例它确实是老牌建模工具功能非常全但安装包大、许可证贵很多学生拿不到正版授权装的时候还会遇到各种环境依赖问题。Navicat 的模型功能做得不错但它本质是数据库管理客户端画 ER 图只是附带功能而且付费版本价格不低。DBeaver 免费开源口碑也很好可它是 Java 桌面应用日常使用中内存占用和启动速度都不算理想在配置普通的笔记本上体验尤其明显。更尴尬的是跨平台协作。我们组之前有同事用 Windows 画图我用 macOS 打开文件字体、布局、连接线的位置全都不一样最后只能截图来回传。不同桌面工具之间的文件格式也互不相通A 工具画的图B 工具根本打不开等于每次换工具都要重新画一遍。1.2 交付场景决定了我们需要轻量我后来想明白一件事大多数情况我们需要的不是一套完整的企业级建模环境而是一张能说明表结构、能表达关系的图。课程设计报告要插图技术文档要附图评审 PPT 要展示多数时候画完图的归宿就是导出 → 放进文档。Web 端工具天然契合这条链路。浏览器打开就能用不需要在每个同事的电脑上都装一遍环境画面随时可以截图也可以导出成 PNG、SVG、PDF 放进各种文档里。更重要的是Web 工具的文件通常就是一段文本JSON、XML 或者 SQL这种东西天然适合放进 Git 里做版本管理团队其他人拉下来就能继续改。1.3 Web 端开源工具现在成熟到了什么程度早期 Web ERD 工具确实是玩具卡顿、糊图、功能残缺老开发者应该都经历过 Flash 时代那种画布拖不动、导出图片糊成一片的体验。但现在的前端技术栈已经完全不一样了现代 Web ERD 工具具备快捷键、框选、对齐辅助线、自动布局、深色模式这些能力操作手感已经很接近原生桌面应用。我在这个领域选工具的标准其实很固定开源协议友好MIT 或 Apache 2.0方便自己改、能自托管数据不经过别人服务器内网也能用、支持从 SQL 导入和导出 DDL、界面响应流畅。以下三款就是我按这个标准筛出来的分别对应三种完全不同的使用场景。2. erd-editor从零设计表结构时我用得最多的 Web ERD2.1 项目画像第一款要介绍的是 erd-editor它在 GitHub 上开源使用 MIT 协议界面风格偏现代化。严格来说它是我目前见过的开源 Web ERD 工具里设计属性最强的一个。它的界面分成三块左侧是表和字段的树形列表中间是画布区域右侧是属性面板。选中任何一个表或字段右侧都能直接编辑字段名、类型、长度、默认值、注释这些信息不需要频繁弹窗。画布支持多选、框选、对齐辅助线这些基础交互做得很扎实。它支持 MySQL、PostgreSQL、MariaDB 三种主流方言并且分为概念模型和物理模型两个层面。这个概念对新手可能有点陌生简单说就是你可以先在概念层面把业务实体和它们之间的关系画出来确认设计没问题后再切到物理模型层面去补字段类型、索引、外键约束这些落库需要的细节。2.2 两种常见用法用法 A先画逻辑模型再生成 DDL这是我最推荐的用法特别适合数据库课程设计、毕业设计和新项目的开局阶段。流程大致是在概念模型里创建实体比如用户订单商品。给每个实体添加字段确定哪些是主键。在画布上建立实体之间的关系工具会用连线把关系表达出来。切换到物理模型补充字段类型、长度、索引、唯一约束。导出 SQL DDL 脚本直接在 MySQL 或 PostgreSQL 里执行建表。这样做的好处是决策顺序正确先想清楚业务关系再落库。很多新手一上来就建表、写字段等画 ER 图时才发现关系和字段对不上返工成本非常高。用法 B从现有数据库反向生成如果你已经有一个跑着的数据库只是想快速得到它的 ER 图erd-editor 也支持通过数据库连接拉取表结构。在导入选项里选择数据库类型、填写地址和账号就能把表结构、主外键关系拉进画布。它也支持直接粘贴 SQL DDL 文件导入这个方式在只想导入个别几张表时很灵活。2.3 我实际用下来的感受先说优点。自动布局功能非常省心几十张表的规模下一键布局就能得到比较清爽的连线排布。中文注释和字段名没有乱码问题这对国内项目很重要。它还带版本历史功能可以像 Git 那样回到之前的某个版本画改坏了大不了回退不用怕。再说局限。第一它只支持 MySQL、PostgreSQL、MariaDB 三种数据库如果你用的是 Oracle 或 SQL Server需要先把数据库导出成通用 DDL 再导入多了一层转换。第二当表数量超过一百张自动布局的效果就会开始变乱需要手动分组和调整。第三多对多关系不会自动帮你拆中间表它只是把两个实体直接连起来业务上的关联表还是要自己建。2.4 适合谁、什么时候用erd-editor 最适合的是从零开始设计的场景。无论你是学生做课程设计还是开发者启动一个新项目只要有我要自己定义表结构的需求它就很有用。反过来说如果你的目的是给一个已经非常庞大、复杂的存量数据库画图它有数据库支持范围的限制可能不如下一款工具顺手。提示erd-editor 的官方站点提供在线体验也可以自己部署到内网。我的习惯是设计阶段用它等表结构定了需要交付精美文档时再换排版工具。3. ChartDB已经有库但没 ER 图时的最快解3.1 这类工具解决的真实问题第二款是 ChartDB它解决的问题和 erd-editor 正好相反。很多时候我们遇到的不是从零设计而是这个系统已经跑了好几年根本没人说得清表结构。存量项目最大的痛点是文档缺失。表几十上百张谁也不敢保证自己记得所有外键关系手工画图画到怀疑人生而且很容易漏关系。ChartDB 的核心思路就是反推连接数据库一键生成 ER 图把表、字段、主外键连线全部可视化出来。3.2 两种接入数据库的方式ChartDB 的使用方式有两种。一种是直接用它的托管服务注册后就能用适合单次快速出图。另一种是自托管官方提供了 Docker 镜像部署到内网之后整个团队就可以共用一套数据库可视化工具所有 schema 信息都留在自己的服务器上不会经过第三方。除了 Web 端之外它还提供了一个命令行工具可以通过 Python 安装。命令行工具负责连接数据库、抓取结构、导出成一个 schema JSON 文件然后在 Web 界面里导入。这种设计对生产环境很友好你可以让运维在跳板机上跑命令行工具拿到 JSON 文件后导入本地的 Web 界面不必把数据库连接信息暴露给每个人。支持的数据库范围比 erd-editor 广不少MySQL、PostgreSQL、SQL Server、MariaDB、SQLite、Oracle 这些主流的都支持还有一些更偏门的数据库可以通过扩展插件支持具体以项目 README 为准。3.3 画图之外它还提供了什么我实际测下来用命令行工具连一个几十张表的 MySQL 库几秒钟就能生成 schema JSON把 JSON 拖进 Web 界面表结构、主外键连线、索引都出来了速度非常快关系识别率也让我意外。但它不只是画图。画布右侧有一个 AI 面板你可以选中一张表让它解释这张表的字段含义和业务用途也可以选中整库让它生成一份表结构说明文档。这个功能对补项目文档来说简直是效率神器。当然AI 功能需要配置大模型 API不配置也不影响画图只是少一个辅助能力。它还支持虚拟表设计模式。意思是你可以在一张已经存在的旧库 ER 图上继续设计新表把新表加到图里最后导出包含新旧表的 DDL 脚本。这个功能在老系统要加新模块的场景下特别好用不需要开两个工具来回切换。3.4 用 ChartDB 的注意事项第一AI 功能依赖外部大模型服务如果你在公司内网使用需要自己对接兼容的 API 服务否则就用不了这个功能。第二部分数据库方言需要安装额外的导入扩展首次使用前先看 README 里的说明否则会报连接错误。第三从数据库反推出来的图默认展示信息很多字段类型、索引、注释全堆在画布上导出前建议先调整显示选项只保留字段名和主外键标记图会清爽很多。4. diagrams.netdraw.io所有 ER 图最终要见人时的排版神器4.1 它为什么能占一个位置第三款是 diagrams.net也就是大家更熟悉的 draw.io。严格来说它不是数据库专用工具而是一个通用绘图工具但我还是坚持把它排进这篇推荐里原因是ER 图最终是要见人的而它是对最终排版控制力最强的开源 Web 绘图工具。很多人忽略了这一点数据库专用工具画出来的图默认样式往往不够好看导出到文档里还需要在 Word 里裁剪、调字体、改颜色。而 diagrams.net 本身就是老牌绘图工具Apache 2.0 协议开源图形库里自带 Entity Relation实体关系形状——就是那种带主键区、外键区的表框也内置了数据库相关的多种形状。它的排版能力是真正的强项字号、颜色、填充、边框、对齐、图层、网格对齐所有细节都可控。画一张漂亮的 ER 图放进毕业设计论文或者方案 PPT它是最可靠的选择。4.2 从 SQL 自动生成 ER 底稿的隐藏功能很多用户不知道diagrams.net 的 Web 版有一个从 SQL 生成 ER 图的功能。在菜单里找到 From SQL不同版本的菜单位置略有差异桌面版通常藏在 Extras 菜单下Web 版在 Insert 相关菜单里把 CREATE TABLE 建表语句粘贴进去它能自动解析出表、字段和关系连线直接生成一张 ER 底稿。这个功能生成的图质量一般连接线位置、表框大小都需要手工调整但它胜在快。你先把 DDL 贴进去生成底稿再用它强大的排版能力慢慢调样式比完全从空白画布开始画效率高得多。4.3 文件、部署与协作diagrams.net 的源文件是 .drawio 格式本质是 XML 文本。这一点非常关键因为 XML 文本可以被 Git 追踪、对比和合并团队协作时不会出现图被他改了但我不知道改了什么的尴尬。它支持把文件直接存到本地、GitHub、GitLab、OneDrive、Google Drive、Dropbox打开和保存都走云端不需要本地安装任何东西。如果团队想在内网统一使用官方提供了 Docker 镜像自托管一个实例所有数据都留在自己的服务器上。另外VS Code 里的 drawio 插件可以直接编辑 .drawio 文件开发者在写代码的窗口里顺手就能改图这个体验非常顺。4.4 它的边界但 diagrams.net 毕竟不是数据库建模工具它不知道什么是外键约束也不理解字段类型是否合法。画布上的表和连线只是图形元素不是数据模型。你在上面画了一个 varchar(255) 的主键它也不会提醒你哪里不合理。它同样不能导出 DDL因为它的底层根本没有模型的概念。所以我对它的定位一直很清晰它是图表工具不是模型工具。模型应该交给 erd-editor 或 ChartDB 这一类工具来维护diagrams.net 负责最后一步排版、美化、导出交付。5. 三款工具怎么选一张对照表和一套组合用法5.1 横向对比为了不让你在选型上纠结我把三款工具的核心差异整理成了表格。维度erd-editorChartDBdiagrams.net定位ERD 编辑器数据库可视化与迁移工具通用绘图工具开源协议MITMITApache 2.0Web 端可用支持在线体验/自托管支持托管服务/自托管支持在线版/自托管从现有库反推支持限 MySQL/PG/MariaDB支持主流数据库覆盖面更广不直接支持需借助 SQL 导入SQL DDL 导入支持支持支持From SQLDDL 导出支持支持不支持逻辑模型设计支持概念/物理两层模型有限支持虚拟表不支持排版精细度中等中等高云存储与团队协作一般一般强上手成本低低低5.2 三种典型场景对号入座如果是数据库课程设计或毕业设计要从需求文档开始设计表结构首选 erd-editor。它允许你从概念模型出发理清实体关系后再落成物理表导出的 DDL 可以直接拿去建库整个过程逻辑非常顺。如果是给老系统补文档或者刚接手一个没人说得清结构的项目首选 ChartDB。连接数据库一键出图配合 AI 生成表说明能在很短时间内把一个陌生库的脉络摸清楚。如果最终交付物要进论文、进 PPT、进对外文档或者团队对图的样式有统一要求就用 diagrams.net 做最终排版。它的绘制精细度是另外两款比不了的。5.3 我的组合用法现实中我很少只用一款工具。新项目建模时我在 erd-editor 里完成设计并导出 DDL建表落地之后再把画布导入或重绘到 diagrams.net 里排版得到一张可以直接贴进文档的论文版 ER 图。老系统需要补文档时我用 ChartDB 快速反推结构先截图丢进方案里应急等有时间再基于反推结果在 diagrams.net 里重新绘制正式版。这里有一个很重要的原则一套数据模型只在一个工具里维护。我见过不少团队同时在三个工具里改同一个模型最后版本漂移ER 图和实际数据库对不上反而制造了更多混乱。建议你以 erd-editor 或 ChartDB 作为模型源头diagrams.net 只做展示层的排版不要两边都改。6. 从 SQL 到 ER 图六个最容易踩的坑6.1 没有物理外键时工具画不出关系线无论哪款工具从现有数据库反推 ER 图时都有一个前提表之间的外键必须在数据库里有物理定义。很多老系统只在业务层面做关联代码里通过 id 去关联另一张表但数据库里根本没有 FOREIGN KEY 约束。这种情况下工具是画不出关系线的它只能看到一张张孤立的表。对策有两个如果只是想出图可以临时在一个测试库副本里补上外键约束再执行反向生成如果需要长期维护建议趁着补图的机会把该加的物理外键一并补上。这类工具的能力上限其实是数据库本身的规范程度决定的。6.2 多对多关系不会自动拆中间表ER 图里的多对多关系在关系型数据库落地时必须拆成一张中间表。但工具不会帮你理解业务它只会把两个实体直接连起来。我在用 erd-editor 时就遇到过学生和课程是多对多工具直接拉了一条线但实际上需要 score 表作为关联表而且这张关联表上还有成绩这个业务字段。所以画图时一定要人工检查多对多关系确认中间表是否已存在、是否带了额外的业务字段。这一步不能省否则图看起来正确建出来的表却不对。6.3 DDL 导入时的中文乱码把 SQL 文件导入 Web 工具时中文注释乱码是出现频率最高的问题。大多数时候问题不在工具而在文件编码。请确保 DDL 文件保存为 UTF-8 编码而不是 GBK 或 ANSI。如果你用的是数据库连接方式也要在连接参数里显式指定字符集比如 MySQL 的连接串带上 characterEncodingutf8 这样的参数。我自己的习惯是从数据库导出 DDL 时先看文件编码再用文本编辑器转成 UTF-8然后再导入工具。这一步花十秒钟能省掉后面一大半修图时间。6.4 自引用表树形结构画出来线很乱组织架构表、菜单表这类自引用表外键指向表本身画布上会出现一条从表指向自己的线而且当表数量多的时候这种自引用线经常和其他连线交叉把图搅得很乱。我的处理方法是在正式交付的图里隐藏自引用线不做删除只是在视觉上收起来然后在图例或文字说明里标注该表存在递归自关联用于表达树形层级。如果你用的工具支持多页或多画布也可以把树形结构单独画到一张局部分图展示效果会清楚很多。6.5 视图、存储过程别硬塞进 ER 图ChartDB 这类工具在反推时有可能会把视图也识别成表。视图在 ER 图里其实很尴尬它本身不存储数据和实体表混在一起会让图异常臃肿。存储过程和触发器同理它们不属于结构图应该表达的内容。建议在导出前先过滤掉非表对象或者单独建一张视图关系图。ER 图的核心价值是表达表与表之间的关系保持图的纯粹性比把所有对象都塞进去更重要。6.6 导出大图的排版细节最后说一个很多人都会遇到的问题图一大了导出 PNG 就糊或者导出后被裁掉一截。我的经验是能导出 SVG 或 PDF 就不要导出 PNG。SVG 是矢量格式放进 Word 和 PPT 里无限放大都不会糊PDF 更适合直接提交打印版文档。导出之前先统一画布尺寸和缩放比例把字体调到一致的风格再检查一次画布边缘的留白。很多工具导出时会按画布内容自动裁剪但自动裁剪经常把边缘的表切掉一半所以画布四周多留一点空白区域导出后再手动裁切通常最稳。说到底ER 图工具只是把思路变成图形的手段真正决定图质量的是模型本身的规范程度。用这些 Web 端开源工具你可以抛开安装环境、许可证、版本不兼容这些杂事把精力集中在实体关系设计上。我自己现在的工作习惯是不管用什么工具动手画图之前先在纸上把业务实体和关系列清楚然后才打开编辑器。命名规范统一、外键约束完整、字段注释写清楚这三件事做到了任何 ER 图工具都能画得很清爽做图效率自然也就上来了。