做数据库设计这几年我最大的感受是ER图这东西重要的不是画得好看而是能准确表达出“谁和谁是什么关系”。但现实中的麻烦在于很多工具要么太笨重装完一年用不了几次要么收费试用期一过就各种限制。后来我干脆把整套工作流搬到Web端——打开浏览器就能画画完直接导出给团队评审省掉了装客户端、换机器、版本不一致这些破事。今天这篇就聊聊我长期在用的3款开源Web端ER图设计工具它们分别是图形化画图工具diagrams.net、专注数据库表结构设计的老牌工具WWW SQL Designer以及把ER图写成文本再由浏览器渲染的Mermaid erDiagram。这三款工具覆盖了三种完全不同的画图习惯有人喜欢拖拽图形有人习惯先建表再连线还有人希望ER图能像代码一样放进Git仓库、用文本维护。不管你是正在做数据库课程设计的学生还是需要在项目里长期维护数据模型的开发者这里面总有一款能对上你的使用习惯。1. 为什么我推荐这三款Web端开源工具1.1 选工具前先搞清楚自己的真实需求很多人一上来就问我“哪款ER图工具最好用”我的回答通常是先别急着选工具先回答三个问题——你多久画一次ER图画完给谁看要不要导出建表SQL这三个问题的答案直接决定了工具选型的方向。举个例子如果你是给课程设计画一张ER图交作业那最核心的需求就是“画得清楚、能放进论文”这时候让代码控去学Mermaid语法就是本末倒置反过来如果你在一个长期维护的项目里每次表结构变更都要同步更新文档那图形界面反而成了负担用文本描述ER图再自动渲染是最省心的方案。这也是为什么我没有推荐那种“全家桶”式的一体化数据库设计平台。在我看来工具之间不是替代关系而是负责不同环节。真正高效的工作流往往是让不同的工具各自做自己最擅长的事最后通过导出和导入把它们串起来。1.2 三款工具的开源协议与基础对比在开箱即用这件事上这三款工具都做到了极致不需要下载安装包不需要配置复杂的运行环境只要浏览器能上网就能干活。如果你有私有化部署的需求它们也都支持部署到自己可控的服务器上数据完全由自己掌握。为了让你一眼看出它们的区别我把核心差异整理成了下面的表格工具开源协议打开即用核心用法SQL导入/导出学习曲线diagrams.netApache 2.0在线版直接访问拖拽画图支持数据库图形库支持从SQL生成表结构极低WWW SQL DesignerGPL-3.0在线Demo/本地部署建表→填字段→连线→导出SQL支持导出标准DDL低Mermaid erDiagramMIT在线编辑器/嵌入文档文本DSL描述关系自动渲染需脚本或手动转换中从表格里能看出来我选工具的底层逻辑是看“产出物”diagrams.net产出的是给人看的图WWW SQL Designer产出的是能直接跑的建表SQLMermaid产出的是一段可复用的文本描述。搞清楚这一点后面所有操作都顺了。2. 三款工具核心能力逐项拆解2.1 diagrams.net能打天下的通用ER图画布diagrams.net是开源的流程图和图表绘制工具Apache 2.0协议可以放心商用。它的在线版地址是app.diagrams.net打开就是画布大部分情况下你甚至不需要注册账号画完直接下载文件走人。很多数据库从业者其实早就用过它但只是把它当普通画图工具用没有发挥出它在ER图场景下的潜力。事实上diagrams.net内置了Database图形库里面有现成的Entity、Table等形状新建图的时候直接选“实体关系”模板画出来的表和常规数据库设计工具一样规整。更关键的一个功能是“从SQL生成ER图”。在菜单栏的Arrange → Insert → Advanced → SQL里把建表语句粘贴进去工具会自动解析出每张表及其字段生成图形化的表结构。这个功能对大表特别有用几十张表手动画得累死用SQL一把梭进来再手动整理布局就行。反过来如果你在画布上画好了实体关系也可以通过Tools菜单里的导出功能把设计转换成SQL脚本。我的日常习惯是把.drawio文件直接存进项目的Git仓库配合VS Code插件Draw.io Integration在编辑器里打开改完图形就相当于更新了文档提交时还有diff可以看。需要发给人评审的时候导出成PNG或SVG沾到IM聊天窗口里就能看对方完全不需要安装任何工具。这也是Web端工具最大的优势之一交付成本极低。2.2 WWW SQL Designer数据库设计专用的Web老炮WWW SQL Designer是一个很老但很经典的开源工具GPL-3.0协议源码托管在GitHub。它和通用画图工具有一个本质区别它是先有表后有图。使用逻辑非常硬核——你直接在建表模式下操作最终产物是一份符合语法规范的SQL DDL。整个界面分三块中间是画布左侧是工具栏和表列表底部是当前表的字段编辑区。在画布上添加一张表之后双击表名可以修改表名在字段编辑区里可以逐条添加字段、设置数据类型、长度、默认值勾选主键、唯一、非空等约束。所有操作都是表单化的不需要像图形工具那样去拖动文本框调整位置。它的杀手锏是工具栏里的“Export DDL”按钮。你可以在下拉框里选择目标数据库类型比如MySQL、PostgreSQL、Oracle、SQLite等然后一键生成建表SQL。对于做数据库课程设计或者小型业务系统开发的人来说这个功能省下了大量手写建表语句的时间而且生成结果规范不容易因为手误漏掉逗号或括号。唯一的短板是它偏老界面是英文而且默认不处理AUTO_INCREMENT这类扩展属性导出后需要自己补一下。但只要你理解了它“面向SQL设计”的理念这个小坑完全不是问题。2.3 Mermaid erDiagram让ER图走进代码仓库Mermaid是一个用文本描述图表的开源项目MIT协议erDiagram是它的ER图模块。它解决的问题很直接ER图可以作为代码存在被版本管理、被diff、被复用。它的语法非常直观核心是三部分实体定义、属性定义、关系定义。实体就是表属性就是字段关系就是表之间的连线。写完一段文本之后把它丢进Mermaid Live Editormermaid.live右侧会自动渲染出对应的ER图。你甚至不需要额外安装任何软件在浏览器里就能完成整个过程。但是Mermaid真正的威力在于嵌入。GitHub和GitLab的原生Markdown渲染器都支持Mermaid意味着你把ER图文本直接写进README里页面打开就是一张图docsify、VuePress等文档站也有对应的插件支持。这意味着什么意味着你的技术文档里不再是一张“静态死图”而是一段可以随代码一起演进、可以review注释的活文本。同事改了表结构顺便改一行ER图代码文档和实现永远是同步的。我自己的项目里有不少ER图就是用.mmd文件存在仓库里配合CI流水线用Mermaid CLImmdc命令自动导出图片统一归档到文档站点。这套流程跑起来之后我再也没手动修过文档里的数据模型图。3. 实操图书馆借书系统ER图三种工具各画一遍3.1 先把表结构想明白再动手下面我用一个最经典的“图书馆借书”案例把三款工具完整走一遍。这个案例在数据库课程设计里出现频率极高实体不多但关系清晰很适合作为上手练习。先理清业务一个读者可以借多本书一本书可以被多个读者借过。如果直接在读者和图书之间画多对多关系在实现上会绕弯子所以标准做法是引入一张借阅记录表把“多对多”拆成两个“一对多”。这里我定义三张核心表读者表BORROWERborrower_id主键、name、phone、reg_date图书表BOOKbook_id主键、title、author、publisher、isbn、stock借阅记录表BORROW_RECORDborrow_id主键、borrower_id外键、book_id外键、borrow_date、due_date、return_date、status关系是BORROWER 1—N BORROW_RECORDBOOK 1—N BORROW_RECORD。下面逐个工具演示。3.2 diagrams.net实操从建表SQL快速反推ER图打开app.diagrams.net新建图的时候选择“实体关系”模板。如果你手头已经有SQL建表语句这一步不用傻傻手动拖方块直接用它的SQL导入功能点击菜单栏Arrange → Insert → Advanced → SQL。在弹出的文本框里粘贴建表SQL注意用标准的CREATE TABLE字段之间逗号分隔最好显式标出主键约束。点击OK后工具会自动把每张表解析成图形放到画布上字段列表会自动展开。手动补关系连线从BORROW_RECORD表的borrower_id字段拉一条线到BORROWER表的主键borrower_id同样从BORROW_RECORD表的book_id拉到BOOK表的主键book_id。设置连线样式比如标上1:N或者在端点上用crows foot记号直观表达外键关系。最终导出如果要放进论文建议导出SVG矢量图或者把PNG缩放比例调到200%清晰度才不会糊。这里说个实操细节从SQL导入生成表非常快但关系线基本不会自动生成因为很多人的建表语句里外键约束写得不完整工具解析不出来。所以流程上我推荐“SQL导入生成表框架 手动连线整理关系”两者结合效率最高。另外如果表特别多建议先打开“View → Diagrams”面板把图形按层次整理好导出的时候才能一张图看全。3.3 WWW SQL Designer实操画表直接出建表语句打开WWW SQL Designer的在线DemoGitHub仓库里有入口链接它没有两分钟上手门槛操作完全是数据库思维在工具栏点击表的按钮然后在画布上点一下生成一张新表默认名字叫table1。双击表头修改表名为borrower。在底部的字段面板里添加字段字段名填borrower_id类型选INT长度可以填11勾选PK主键。继续添加name、phone、reg_date等字段类型分别选VARCHAR和DATE。用同样方式创建book和borrow_record两张表。注意borrow_record里的borrower_id和book_id类型也选INT但不要勾选PK它们后面要作为外键。建立关系点击borrower表的borrower_id字段会高亮然后直接拖拽到borrow_record表的borrower_id字段上松手后会自动生成一条关系连线。book到borrow_record同理。点击工具栏里的Export DDL按钮选择目标库为MySQL弹出框里就是完整的建表SQL直接复制到MySQL客户端里就能执行。别忘了保存一份XML格式的设计文件这个是它自己的工程文件下次还能接着改。我有一次给一个课程设计项目做快速原型整个ER图加建表SQL不到10分钟就搞定了最后交上去的作业分数还很高。当然也有坑比如它生成的SQL默认不会加上AUTO_INCREMENT主键需要自己手工补上“AUTO_INCREMENT”关键字还有就是在下拉框里选择类型时要留意MySQL的VARCHAR需要带长度否则导出SQL里会少参数。3.4 Mermaid erDiagram实操用文本描述图书馆借书模型如果用Mermaid这段ER图的源码长这样我把它写成text块方便阅读erDiagram BORROWER ||--o{ BORROW_RECORD : 借阅 BOOK ||--o{ BORROW_RECORD : 被借 BORROWER { int borrower_id PK varchar name varchar phone date reg_date } BOOK { int book_id PK varchar title varchar author varchar isbn int stock } BORROW_RECORD { int borrow_id PK int borrower_id FK int book_id FK date borrow_date date due_date date return_date varchar status }把这段文本复制到mermaid.live左侧编辑器里右侧立刻渲染出一张关系图。关系行的含义要理解清楚||--o{表示“一个读者对应零个或多个借阅记录”前面的||读作“恰好一个”后面的o{读作“零个或多个”。方向是从父表指向子表配合关系标签一眼就能看出业务含义。渲染确认没问题后你可以直接下载SVG或PNG也可以把这段文本直接粘贴到GitHub的Markdown文件里页面会自动渲染成图。需要批量导出时就装mermaid-js/mermaid-cli命令行里一句话把.mmd文件转成图片mmdc -i library.mmd -o library.png -w 1200 -b white这个工具链对我这种长期和文档打交道的人来说简直是福音因为ER图和代码共用一套版本管理逻辑改没改、改了什么全都有迹可循。4. 实战中踩过的坑和排查技巧4.1 diagrams.net相关问题我在diagrams.net里遇到最多的问题是从SQL导入生成ER图后关系线缺胳膊少腿。分析下来基本都是SQL语句里没有写外键关联导致的工具自然无法推断关系。所以要么在SQL里显式加上FOREIGN KEY约束要么干脆接受“先导入再手动连线”这个流程心里有预期就不会烦。另一个常见问题是导出的图片清晰度不够。特别是要放到论文里或者放大看字段名时默认的PNG导出偏模糊。解决方式很简单导出时在设置里把缩放比例调到200%或者直接导出SVG在Word里插入SVG后放大不会失真。4.2 WWW SQL Designer相关问题老项目普遍存在现代浏览器兼容性问题WWW SQL Designer也不例外。我实测Firefox和Edge偶尔会出现按钮点击没反应、字段下拉框渲染异常的情况换成Chrome后一切正常。如果你遇到界面卡顿或者按钮失灵优先换浏览器。再就是误刷新导致整个设计丢失。这个工具没有自动保存你画到一半手一滑按了F5全部白干。我的习惯是每完成一张表就点一下保存按钮把XML文件下载到本地做到“表级保存”。别嫌麻烦这个习惯在关键时刻能救命。还有一个细节是导出SQL时注意目标数据库类型的选择。默认模板和不同数据库的方言有差异比如PostgreSQL和MySQL在自增字段、引号风格上就不一样。导出后最好先到数据库里跑一遍确认没问题再继续。4.3 Mermaid erDiagram相关问题Mermaid在中文环境下最大的问题是字体。在mermaid.live里渲染一般没问题但用CLI导出图片时如果系统缺少中文字体生成的PNG里中文可能变成方块或者乱码。解决办法是给mmdc指定适合的字体配置或者在容器环境里安装中文字体包。还有一点Mermaid是自动布局不能像图形工具那样手动拖动每个节点。一旦实体多、关系复杂图会变得比较拥挤。我的经验是尽量把ER图拆分成多个子图比如“用户域”“订单域”“库存域”各一张阅读起来比一张巨图清晰得多渲染性能也好。4.4 常见问题速查表为了方便你以后排查我把上面这些经验整理成了一张速查表问题现象可能原因解决方法diagrams.net导入SQL后无关系线SQL中未写外键约束手动连线或在SQL中补全FOREIGN KEY导出的图片放大后模糊默认DPI低导出SVG或设置缩放200%WWW SQL Designer按钮没反应浏览器兼容性问题换Chrome浏览器画到一半设计丢失没有保存工程文件每张表完成后导出XML备份导出SQL缺少自增属性工具默认不处理AUTO_INCREMENT导出后手动补充Mermaid图片中文乱码渲染环境缺少中文字体安装中文字体或指定字体配置Mermaid节点布局混乱实体多且关系复杂拆分子图按业务域拆分写在最后的话我现在的使用习惯基本固定下来课程设计、快速原型这类一次性的任务优先上WWW SQL Designer因为它能把表结构设计直接变成建表SQL效率是第一位的正式文档、对外汇报、论文配图用diagrams.net因为它能产出漂亮且可控的交付物而长期维护的项目尤其是有多人协作和文档沉淀需求的必然选Mermaid erDiagram让ER图作为代码仓库的一部分持续演进。最后分享一个我踩过很多次坑之后总结出来的习惯不管用哪个工具先拿张纸或者白板把实体、主键、外键、关系列个草稿然后再开电脑落到工具里。很多时候你在软件里反复拖拽、反复修改根本问题不是工具不好用而是业务关系没想清楚。ER图的本质是帮我们理清数据模型工具只是表达手段别把精力浪费在折腾工具上。