-
buo4 技术教程组 用户
设计数据库的时候，最烦的不是想不清楚表结构，而是画完图之后还要手写一遍建表语句。
图上加一个字段，SQL 里就得同步改一次，改来改去两边对不上，最后以哪个为准都说不清。
drawDB 把这两件事合并成了一件事。
图与 SQL 分离的老问题
传统做法通常是这样：
先用工具画图。 用绘图软件或者专业建模工具把表结构画出来。
再手写 DDL。 照着图一条条写 CREATE TABLE，字段类型、索引、外键约束全都要手动对应。
然后改需求。 需求一变，图和 SQL 都要改，两边开始不同步。
最后评审。 评审时大家看的是图，但实际执行的是 SQL，中间可能已经对不上了。
问题不在于工作量，而在于同一份信息被维护了两遍。
drawDB 能做什么
纯浏览器运行。 打开网页就能用，不需要安装任何客户端。也可以自己部署一份，数据不外传。
拖拽建表。 画框、加字段、连关系线，外键关系用连线直观呈现，拖一下就能调整。
实时 SQL 预览。 设计的同时生成建表语句，支持 MySQL、PostgreSQL、SQLite 等常见方言。图就是 SQL，SQL 就是图。
导入已有结构。 可以导入 SQL 或已有的 schema，反向生成 ER 图——接手陌生老项目时特别有用。
导出图片与脚本。 图能导成图片贴进设计文档，SQL 能直接复制到数据库里执行。
适合的使用场景
| 场景 | 是否合适 |
|---|---|
| 新项目建表设计 | 非常适合 |
| 接手老库理清关系 | 适合，可导入反向生成 |
| 团队评审表结构 | 适合，导出图片贴文档 |
| 生产库在线变更 | 不合适，只做设计 |
需要明确的是，drawDB 是设计工具，不是数据库管理工具。它不连你的生产库、不做数据迁移、不做在线变更。它的职责就是"把表结构想清楚并落成 SQL"。
使用流程
- 打开或部署 — 直接用官网在线版，或者把自己的实例跑在内网，敏感的表结构不用上传到任何地方
- 画表建关系 — 新建表、加字段和类型、拖动连线建立外键关系
- 导出 SQL — 确认无误后复制建表语句，拿到数据库里执行
什么情况下它不够用
需要团队协作和版本管理时。 drawDB 更偏向个人设计工具，如果你的团队需要多人同时编辑、需要 schema 变更的版本记录和审批流，那需要考虑更完整的方案。
数据库方言很特殊时。 它覆盖主流方言，但如果你用的是某些专有语法，可能需要手工补充调整。
需要自动生成 ORM 代码时。 它输出的是 SQL，不是模型代码。
但在"快速把表结构想清楚，并且顺手拿到可执行的 SQL"这个核心场景上，drawDB 的效率明显高于"画图工具 + 手工写 SQL"的组合。