drawDB：在浏览器里画数据库 ER 图并直接生成 SQL

drawDB 值得用吗

如果你的工作流里存在"先画出表结构、再落到建表语句"这一环，drawDB 是目前把这段距离压到最短的免费工具：不用注册、不用装客户端，打开网页就能拖拽建表、连线设外键，然后导出 MySQL、PostgreSQL、SQLite 等七种方言的 DDL，甚至直接生成表结构变更的迁移脚本。

它不打算替代重型建模工具，恰恰相反——它把自己限制在"从想法到可执行 SQL"这一段。后面你会看到，这个边界既是它的优点，也是它在某些场景下该被放下的原因。

这篇文章按一条路径往下走：先看懂它定位在哪、能力有哪些，再用一个"用户-订单"的例子把"画图 → 建表 → 生成迁移"完整串一遍，最后给自托管方式和选型建议。读完你既能立刻上手，也知道哪些坑要绕开。

功能别背，拆成一条主线和两条支线

drawDB 的功能如果平铺成清单会显得又多又散。拆成一条主线和两条支线更好记：

主线决定"从想法到 SQL 的最快路径"，两条支线分别解决"既有库怎么读明白"和"用完怎么不把设计泄露出去"。下面逐条展开。

主线：画图到 SQL，为什么能一站到底

可视化建表，先有"为什么"

很多建模工具要你先记字段类型的语法细节，drawDB 把这一步图形化：在画布上放一张表卡片，逐个加字段，定义名称、类型、约束（NOT NULL、UNIQUE、主键、自增）。拖拽只是表象，真正值钱的是它把设计与实现解耦：你只需要表达"这张表有哪些列、什么约束"，具体的语法交给工具在导出时处理。

多方言导出：一件事，为什么配七种语法

同一个设计，落到不同数据库，自增和类型写法完全不同：PostgreSQL 用 SERIAL，MySQL 用 AUTO_INCREMENT，SQLite 的 ALTER TABLE 支持很受限。如果设计工具只认一种方言，换个库就得重画，这个成本往往被低估。

drawDB 支持的方言有七种：MySQL、PostgreSQL、SQLite、MariaDB、SQL Server、Oracle（仍标 Beta）以及一个跨库建模用的 Generic 通用模式。画布上的设计是"通用层"，导出时才针对所选方言翻译成对应 DDL——设计一次，换库不重画。

迁移脚本：比较两次设计，得出差异

结构总在变。drawDB 记下当前设计，你在上面加列、删表、改约束后，切到迁移面板，它会比较修改前后的两个状态，输出对应的 ALTER TABLE 增量语句，而不是让你手写 diff。这对"评估一次变更会影响多少表"特别有用。

自动检测问题

提交导出前，工具会扫一遍图里的不一致：外键指向不存在的列、类型明显不兼容、重复约束之类。它把低级错误挡在生成 SQL 之前，相当于给"画的图"做了一圈校验。

支线一：反向工程，从 DDL 重建一张图

接手一个没有文档的旧库，往往只有一坨建表脚本。drawDB 支持把粘贴进来的 SQL DDL（也支持 DBML）反向解析成 ER 图：识别 CREATE TABLE、补全字段、根据外键自动拉出表间连线。你不需要手动重画，贴进去几秒就得到一张可拖拽、可缩放的关系图。这条支线和主线正好互逆——主线是"图 → SQL"，它是"SQL → 图"。

支线二：零摩擦使用，数据留在本地

免费版不用注册，设计保存在浏览器的 IndexedDB 里（注意不是 LocalStorage，容量更大、适合存结构数据）。因为是纯前端应用、不请求任何后端，数据不离开浏览器，页面加载后断网也能继续画。需要说清楚的是：drawDB 没有 Service Worker，不算严格意义的 PWA，别指望离线安装；换设备或清缓存前，记得导出一次 JSON 备份。

一个例子：把上面的机制串起来

机制单独看是静态的。用最小业务串一遍，看它们怎么配合。

第一步，新建一个空图。在画布上建两张表：

• users：id、email
• orders：id、user_id、amount

第二步，把 orders 的 user_id 拖到 users 的 id 上，建立外键关系，图里出现一条连线。

第三步，打开 SQL 面板，方言选 PostgreSQL，复制生成的 CREATE TABLE 语句——你会发现 users.id 导出成了 SERIAL PRIMARY KEY，而 MySQL 方言下会是 AUTO_INCREMENT。字段类型取决于你在画布上选的，这里按常见选择导出，大致长这样：

CREATE TABLE "users" (
  "id" SERIAL PRIMARY KEY,
  "email" VARCHAR(255) NOT NULL
);

CREATE TABLE "orders" (
  "id" SERIAL PRIMARY KEY,
  "user_id" INTEGER NOT NULL,
  "amount" DECIMAL(10, 2) NOT NULL,
  FOREIGN KEY ("user_id") REFERENCES "users" ("id")
);

第四步，回到画布给 users 加一列 created_at，再切到迁移面板，让它比较修改前后，生成对应的 ALTER TABLE 增量语句，而不是手写 diff。

到这里，“画图 → 建表 → 迁移"这条主线就被完整走了一遍，而且全程没碰过 SQL 编辑器。

技术实现与自托管

drawDB 是纯前端应用：React + Vite + Tailwind CSS。表格卡片以 DOM 节点渲染在无限画布上，表间连线走 SVG 路径，整体不依赖后端，所以能静态部署。核心数据指标：仓库约 3.8 万 Star、3.1K Fork（2026-09），AGPLv3 协议，约 99% 是 JavaScript，项目仍保持活跃维护。

本地开发：

git clone https://github.com/drawdb-io/drawdb
cd drawdb
npm install
npm run dev

启动后访问 http://localhost:5173（Vite 默认端口）。

Docker 自托管（官方推荐方式）：

git clone https://github.com/drawdb-io/drawdb
cd drawdb
docker compose up -d

启动后同样访问 http://localhost:5173。注意 compose 起的是 Vite 开发服务器，适合内网自用和试跑；对外稳定服务，用 npm run build 产出静态文件交给 Nginx，或按 README 的 Dockerfile 构建镜像（docker run -p 3000:80）。

需要分享功能（比如通过 GitHub Gist 发链接给团队评审）时，才额外部署配套的 drawdb-server，按 .env.sample 配置环境变量。不部署它，画图和导出 SQL 不受影响。

顺手能用上的细节

主线之外还有几样免费功能，不展开讲，用到时知道有就行：

• 模板：内置几套常见场景的预设表结构，起步不用从空画布开始；自己常用的结构也能存成自定义模板，下次直接加载。
• 快捷键：常用操作都配了快捷键，官方文档有完整清单。
• 演示模式：把画布全屏投出来，适合评审会上对着大屏讲表结构。
• 编辑辅助：撤销 / 重做、复制粘贴、复制表，还能把表归进"主题区域”、给表加备注。

这些都在免费版里，不需要注册。

适用边界

适合：

• 项目早期把表结构画出来，和产品、后端一起评审
• 教学场景：讲数据库设计、ORM 关联关系，比甩 DDL 直观
• 反向工程：快速读懂没有文档的历史库
• 生成迁移脚本，评估一次结构变更的影响面

不适合或要注意：

• 上百张表的大库：DOM 渲染会明显变卡，drawDB 不是为超大规模建模设计的
• 多人实时协同：开源版没有这项能力，需要付费的 Team 版
• 直接执行 DDL：drawDB 只生成 SQL，不连库执行，你仍需拿到目标库跑一遍
• 闭源商业项目：AGPLv3 要求衍生作品同样开源，改源码前先评估协议影响

常见问题

画完的数据存在哪？会不会丢？ 存在浏览器的 IndexedDB 里。同设备同浏览器不清缓存就不会丢；换设备、换浏览器或清缓存之前，先用导出功能备份一份 JSON。

必须联网才能用吗？ 页面加载之后不用。设计存在浏览器本地，画图和导出都不依赖网络；但项目没有 Service Worker，清掉缓存后首次打开仍需联网拉取应用资源。

Oracle 支持到什么程度？ 官方标注为 Beta。常规建表与导出可用，涉及 Oracle 特有语法时建议先跑一个小样例验证，别直接上生产库。

能在 CI 或自动化流程里用吗？ 可以。图能导出成 JSON，可供脚本读取；社区还有 drawdb-mcp 这类 MCP 服务器，让 AI 代理在设计阶段操作并导出可部署的 SQL。

下一步怎么用

给你三条参考路径，按场景选：

• 偶尔画张图：直接用官网编辑器，不需要注册，画完导出 SQL 即可。
• 对数据敏感或要内网用：走 Docker 自托管，把设计留在自己的网络里。
• 想在设计阶段接自动化：导出 JSON 或接 drawdb-mcp，把"设计 → SQL"链进脚本或代理流程。

一句话收尾：drawDB 解决的不是"画图画得多精致"，而是"从结构想法到可执行建表语句"这件事能不能五分钟内做完。想清楚这一点，它值不值得用就不难判断了。