1. 反向工程失败不是DBeaver的问题，是元数据在“装死”
我第一次在客户现场用 DBeaver 对一个运行了七年的 Oracle 12c 生产库做 ER 图反向工程时，界面卡在“正在加载表结构”整整 4 分钟，最后弹出一行红字：“无法获取外键约束信息”。同事立刻说：“换 Navicat 吧，它快。”
我没换。因为我知道——Navicat 同样会失败。问题不在客户端工具，而在数据库里那几行被遗忘的COMMENT ON COLUMN、那个没建索引的CONSTRAINT_NAME字段、还有那个被 DBA 手动删掉又没同步到ALL_CONS_COLUMNS视图里的外键定义。
DBeaver 的 ER 图反向工程（Reverse Engineering）本质是一次元数据采集 + 关系推断 + 可视化渲染三阶段流水线。它不读你的 SQL 脚本，也不猜你的业务逻辑；它只信任INFORMATION_SCHEMA（MySQL/PostgreSQL）、ALL_*视图（Oracle）、sys.*系统表（SQL Server）里明文记录的字段类型、主键标记、外键引用路径和注释文本。一旦这些元数据缺失、错位或权限受限，AI 编程工具再强也无从“辅助”——它连“这张表叫什么”都拿不准，更别说帮你生成关联查询或校验约束完整性。
这正是当前 AI 编程落地中最隐蔽的断点：我们花大力气训练模型理解语义、优化提示词、接入 LLM API，却默认数据库元数据“天然完整”。而现实是，90% 的遗留系统里，元数据就像老房子的电路图——图纸存在