ChartDB：一条查询出数据库图表，跨库 DDL 导出

ChartDB：一条查询出数据库图表，跨库 DDL 导出

【免费下载链接】chartdbDatabase diagrams editor that allows you to visualize and design your DB with a single query.项目地址: https://gitcode.com/GitHub_Trending/ch/chartdb

周五下午，架构组问：「MySQL→PostgreSQL 迁移评估，三天内要结论。」wiki 里的 ER 图是两年前的，生产库权限又查不了 information_schema。像 ChartDB 这样的数据库图表编辑器，一条查询画出全库 ER 图，正解这种局。

它能做什么

• 跑一条预置智能查询，全库的表、字段、外键、索引变成一张 ER 图，全程不碰数据库密码。对不能直连生产的开发者最有用
• 导入 DBML 文件或粘贴 SQL 建表语句，得到可编辑的可视化图表，拖拽即可加表、加关系。对团队设计评审最有用
• 选目标库方言导出一整套 DDL，AI 自动处理跨库的类型映射。对跨数据库迁移 PoC 最有用
• 在画布上用分区、注释、颜色把业务模块归组，乱线团变成能进文档的图。对新成员入职读库最有用

上手体验：从文件到出图

跑起来一个 ChartDB

它是纯前端项目，本地起服务不需要任何数据库账号，ChartDB 本身也不保存你的连接凭证：

git clone https://gitcode.com/GitHub_Trending/ch/chartdb cd chartdb npm install npm run dev

本地起来后直接在浏览器打开。默认构建不带 AI 能力，需要 AI 导出时，构建时注入 OpenAI Key 或自定义推理端点即可。

给 ChartDB 喂一条智能查询

在导入页选择你的数据库类型，ChartDB 会为对应方言生成一条预置查询。拿这条查询到你的客户端（psql、SSMS 之类）里跑，把返回的 JSON 全选贴回 ChartDB，图表立刻渲染出来。整个过程不需要给 ChartDB 任何数据库账号。

在画布上编辑表结构

图出来之后就是可编辑的：双击表增删字段、改类型；从主键拖到另一张表的字段上即建立外键；用分区框圈出业务模块、贴注释。也可以反过来，先写 DBML 文本再导入：

Table users { id int [pk, increment] username varchar(50) [unique, not null] email varchar(100) [not null] created_at timestamp [default: `now()`] } Table posts { id int [pk, increment] title varchar(100) [not null] user_id int [ref: > users.id] indexes { (user_id, id) [name: idx_user_posts] } }

导入会自动识别主键、唯一约束、引用关系和索引，不需要手工连线。

导出 DDL 和 DBML

设计完成后在导出对话框里选格式：DBML 文件可进 git 做版本控制和协作评审；目标库 DDL 有两条路径——PostgreSQL、MySQL、SQL Server、SQLite 走确定性模板，其余方言走 AI 转换；也可以直接导出图片贴进文档。

底层机制速览

DBML 与图表的双向转换

导入、导出、应用是三件套：import 把 DBML 文本解析成内部结构，export 把画布图表还原成标准 DBML，apply-dbml 把新 DBML 的变更应用到已有图表上。三个模块各自挂着成批的测试用例，覆盖复合主键、检查约束、跨 schema 关系这类容易出错的场景。实现集中在 src/lib/dbml/。

智能查询怎么提取元数据

每种支持的数据库对应一份手写提取脚本，从系统视图里聚合表、字段、主键、外键、索引、视图信息，拼成一个 JSON 字符串返回。客户端只需跑这一条查询并把结果贴回来，不需要任何驱动和凭证。脚本按方言组织在 src/lib/data/import-metadata/scripts/。

多方言 DDL 生成

导出分两条路：确定性模板按库各写一套生成逻辑，覆盖 PostgreSQL、MySQL、SQL Server、SQLite；模板没覆盖的目标库走 AI 转换。另有一个 cross-dialect 模块专门做方言间类型映射，所以「MySQL 结构出 PostgreSQL 脚本」这类跨库迁移脚本也是同一套代码产出的。代码在 src/lib/data/sql-export/。

真实场景怎么用

新成员入职读库

遗留系统两百张表、没有文档负责人。用智能查询生成全图后，把 DBML 文件和导出的图一起交给新人：先看整体布局，再按分区找自己负责的模块，顺藤摸瓜读字段。效果：新人从「到处问人」变成半小时自助读完核心链路。

季度架构评审

评审前要确认线上真实结构与设计文档是否一致。导入最新智能查询结果，把图当基准，用注释标出实际与设计分歧的字段和关系，用分区框出各服务边界。效果：评审会直接对着「与线上一致」的图开，分歧当场定结论。

跨数据库迁移 PoC

MySQL 要迁 PostgreSQL，先估算 DDL 改造量。导入生产结构后走 AI 导出 PostgreSQL 脚本，重点核对没有直接映射的类型，再在 PoC 环境对空库跑一遍验证。效果：脚本第一天就能拿到手，评审会前只剩数据迁移方案的活。

容易踩的坑

• 导入大库后页面卡顿 → 智能查询返回全量元数据，单图渲染数千对象吃力 → 先按 schema 过滤，或拆多个图表分批导入
• AI 导出脚本里有类型错误 → LLM 映射不了全部冷门类型和方言特性 → 上线前务必在测试库执行一遍并 diff
• DBML 导入个别字段报错 → 厂商私有类型不在 DBML 规范内 → 导入后手工改对应表的类型
• 本地部署没有 AI 导出 → AI 功能依赖构建时注入的 API Key 或自定义端点 → 没条件就退回到模板导出，只用方言内导出
• 图表和线上库对不上 → 它只读查询结果 JSON，不保持数据库连接 → 把图当「快照」，结构变更后重跑查询

收尾

回到开头那个三天的迁移评估：第一天跑智能查询出 MySQL 全图，核对完 wiki 文档；同一天导出 PostgreSQL DDL 脚本给评审用，PoC 就启动了。ChartDB 以 AGPL v3.0 协议开源，自建部署免费，要把它嵌进商业 SaaS 的话，签约前先看一眼协议条款。

【免费下载链接】chartdbDatabase diagrams editor that allows you to visualize and design your DB with a single query.项目地址: https://gitcode.com/GitHub_Trending/ch/chartdb