1. 为什么我最终把数据库建模从商业软件迁到了PDMan做后端开发时间长了数据库建模这件事几乎绕不开。早些年团队里清一色用PowerDesigner画物理模型、生成DDL、导出字段文档一套流程走下来确实顺手。但问题也很明显正版授权费用不低团队里不可能人手一份装完之后启动慢打开一个稍大的模型文件要等半天更麻烦的是它生成的模型文件是二进制或者私有格式想放进Git做版本管理几乎不可能每次改完模型只能靠截图或者导出SQL来对比差异协作起来非常别扭。后来我开始找替代方案试过几款在线建模工具也试过直接用文本描述表结构但都不太满意。在线工具的问题是数据放在别人服务器上公司内部项目不太放心纯文本方式又缺少可视化跟产品、测试沟通表结构时很费劲。直到接触到PDMan才算找到一个比较平衡的落点。它是一款开源免费的数据库建模工具定位就是替代PowerDesigner这类商业软件支持可视化建模、一键生成DDL、导出数据库设计文档而且模型文件是JSON格式可以直接纳入Git管理。这篇文章我打算把PDMan从选型理由、核心概念、实操建模、版本管理到踩坑经验完整讲一遍。适合正在找PowerDesigner替代方案的开发者、需要维护数据库设计文档的团队以及想把手头建模工作流规范起来的人。不管你是刚接触数据库建模的新手还是用了多年商业软件想迁移的老手应该都能从里面找到能直接用的东西。2. PDMan到底解决了PowerDesigner的哪些痛点2.1 授权成本与团队协作的现实矛盾PowerDesigner是商业软件按席位收费一个团队如果只有一两份授权就意味着只有少数人能打开模型文件。实际工作中产品经理要确认字段含义测试要核对表结构后端同事要新增字段所有人都得排队等那个有授权的人来改模型效率极低。PDMan是开源免费的没有席位限制团队每个人都能装、都能打开模型文件这一点直接改变了协作模式。我印象很深的一次经历是之前用商业软件时一个字段注释的修改要经过提需求—等授权同事改—导出文档—发群里这么一条链路来回至少半天。换成PDMan之后模型文件就在项目仓库里谁需要改谁就改改完提交其他人拉下来就能看到整个链路缩短到几分钟。2.2 模型文件的版本管理难题这是我认为PDMan最核心的优势。PowerDesigner的模型文件是私有格式Git没法做有意义的diff你只能看到二进制文件已更改根本不知道改了哪个字段。PDMan的模型文件是.pdm后缀本质是JSON字段的增删改在Git里一目了然。{ entities: [ { name: user_account, chnName: 用户账户表, fields: [ { name: id, type: BIGINT, chnName: 主键ID, pk: true } ] } ] }上面是简化后的结构示意实际文件会更复杂但核心就是这种可读的键值对。这意味着代码评审时评审人可以直接在diff里看到新增了一个phone字段类型VARCHAR(20)而不是对着一堆乱码猜。对于需要严格管控数据库变更的项目来说这个特性价值极高。2.3 跨数据库方言的适配能力实际项目里经常遇到一种情况开发环境用MySQL生产环境可能是Oracle或者PostgreSQL甚至同一个系统要同时支持多种数据库。PowerDesigner支持多数据库但切换和配置相对繁琐。PDMan内置了主流数据库的方言模板建好模型后可以一键切换目标数据库直接生成对应方言的DDL。它支持的数据库包括MySQL、Oracle、SQL Server、PostgreSQL、SQLite、达梦等基本覆盖了国内项目常见的选型。切换数据库时字段类型会自动做映射比如MySQL的INT在Oracle里会映射成NUMBER虽然映射结果不一定100%符合你的预期但至少省去了大量手工调整。2.4 数据库设计文档的自动导出很多团队都有维护数据库设计文档的需求但手工维护的文档往往和实际表结构脱节时间一长就没人看了。PDMan可以根据模型直接导出Word或HTML格式的设计文档包含表名、字段名、中文名、类型、是否主键、注释等信息。模型一改文档重新导出即可保证文档和模型始终一致。提示导出的文档建议纳入项目的文档目录和模型文件一起提交这样文档的历史版本也能追溯。3. 上手PDMan前必须搞清楚的几个核心概念3.1 数据表实体与字段属性PDMan里最基础的单位是数据表实体对应数据库里的一张表。每个实体有表名物理名和中文名表名建议用英文加下划线的命名规范中文名用于文档展示和团队沟通。实体下面挂字段每个字段有物理名、中文名、数据类型、长度、是否主键、是否非空、默认值、注释等属性。这里有个容易忽略的点字段的中文名和注释是两个不同的属性。中文名主要用于PDMan界面和导出文档的展示注释则会写进生成的DDL里成为数据库层面的COMMENT。我建议两个都填中文名给团队看注释给数据库看这样无论从哪个入口查表结构都能看懂。3.2 数据域与字段复用数据域是PDMan里一个很实用的概念可以理解成字段模板。比如你有很多表都有创建时间这个字段类型统一是DATETIME注释统一是创建时间那就可以定义一个数据域建表时直接引用不用每次重复填类型和注释。数据域的好处是统一规范。如果哪天要把所有创建时间从DATETIME改成TIMESTAMP只需要改数据域的定义所有引用它的字段会同步更新。这在字段规范经常调整的项目里能省下大量重复劳动。3.3 关系与视图PDMan支持在实体之间建立一对一、一对多、多对多的关系建立后会在模型图上用连线表示。关系本身不会直接生成外键约束是否生成可以在设置里控制但能让模型图更直观地反映业务逻辑。视图功能则允许你把常用的多表关联查询定义成视图一并纳入模型管理。视图的SQL可以直接在PDMan里编写导出DDL时会一起生成。3.4 模型分组与模块化当表数量多起来之后把所有表堆在一张图上会非常乱。PDMan支持把实体分组比如按业务模块分成用户中心订单中心商品中心等。分组之后模型图可以按组查看导出文档时也能按组组织章节结构清晰很多。我的习惯是项目初期就规划好分组哪怕一开始只有几张表。因为后期表多了再拆分调整分组关系会很麻烦不如一开始就按业务边界分好。4. 从零建一个可用的数据库模型完整实操流程4.1 安装与初始配置PDMan是跨平台的Windows、macOS、Linux都有对应安装包从官方仓库下载即可。安装过程没什么特别的一路下一步就行。首次启动后建议先做几项配置在设置里配置默认的数据库类型这样新建模型时会默认用你常用的方言。配置代码模板PDMan允许自定义DDL生成的模板如果团队有特殊的建表规范比如必须带ENGINEInnoDB可以在这里改。设置默认的字段类型映射把常用的类型对应关系固化下来。注意PDMan的配置是跟着安装走的换电脑后需要重新配置。如果团队有统一规范建议把配置导出成文件共享避免每个人配得不一样。4.2 新建模型与数据库选型新建模型时PDMan会让你选择目标数据库。这个选择决定了后续字段类型的可选范围和DDL生成的方言。如果项目要支持多种数据库建议先按主数据库建模型需要时再通过数据库转换功能生成其他方言的版本。模型建好后先别急着画表花几分钟把分组规划好。我一般会按业务域建几个分组比如基础数据业务主表日志审计等。分组规划好之后后面建表时直接往对应分组里放模型图不会乱。4.3 建表与字段定义的具体操作建表的过程很直观在分组上右键新建实体填表名和中文名然后逐个添加字段。每个字段需要填物理名、中文名、类型、长度、是否主键、是否非空、默认值、注释。这里分享几个实操中的经验主键统一用BIGINT自增避免用业务字段做主键。业务字段可能变化主键一旦定了就不该改。所有表都加create_time和update_time两个字段用数据域统一管理类型用DATETIME默认值CURRENT_TIMESTAMP。字段注释一定要填而且要写清楚业务含义不要写用户ID这种废话要写关联user_account表的主键标识该记录归属的用户。字符串类型长度要合理不要一律VARCHAR(255)。手机号用VARCHAR(20)身份证号用VARCHAR(18)名称类字段根据实际业务定长度。4.4 生成DDL并验证模型建好后点击导出DDL就能生成建表语句。生成之前建议先检查几项检查项说明表名规范是否统一小写加下划线是否有前缀字段类型是否符合目标数据库的规范主键设置每张表是否都有主键注释完整性表和字段注释是否都填了索引设计常用查询字段是否建了索引生成的DDL建议先在测试库执行一遍确认没有语法错误、类型不兼容等问题再上生产。PDMan生成的DDL是标准SQL但不同数据库对某些语法支持有差异实测一遍最稳妥。4.5 导出数据库设计文档在导出菜单里选择导出文档可以选Word或HTML格式。导出的文档会按分组组织每张表一个小节列出所有字段的详细信息。文档的样式可以在模板里调整比如加上公司抬头、调整表格样式等。我通常会把导出的文档放到项目的docs目录下和模型文件一起提交。这样新同事入职时看文档就能了解数据库结构不用去翻代码里的建表语句。5. 把PDMan模型纳入Git工作流的实操细节5.1 模型文件的提交与diff阅读PDMan的模型文件是JSON提交到Git后每次修改都能看到清晰的diff。但JSON文件通常是一整行或者格式化后很长直接看diff可能不太直观。建议在提交前用编辑器的格式化功能把JSON格式化一下这样diff会按字段逐行展示可读性大幅提升。实际评审时diff里能看到类似这样的内容{ name: phone, chnName: 手机号, - type: VARCHAR, - len: 11 type: VARCHAR, len: 20 }评审人一眼就能看出手机号字段长度从11改成了20非常直观。5.2 多人协作时的冲突处理多人同时改模型文件时Git冲突是难免的。因为JSON是文本格式冲突可以手工解决但需要小心。我的经验是尽量按模块分工不同人改不同分组的表减少冲突概率。如果冲突了不要直接选接受当前或接受传入要打开文件逐段对比确认两边的修改都要保留。解决完冲突后一定要在PDMan里打开模型确认没有损坏再提交。提示PDMan打开模型时会做格式校验如果JSON结构被破坏会提示文件损坏。所以解决冲突后务必用PDMan验证一遍。5.3 模型变更与DDL变更的同步模型改了之后数据库也要跟着改。PDMan本身不直接连数据库执行变更需要你导出DDL后手工执行。对于已经上线的表直接执行CREATE TABLE会报错需要改成ALTER TABLE。PDMan有一个数据库同步的功能可以对比模型和实际数据库的差异生成变更脚本。但这个功能需要配置数据库连接而且对比结果不一定完全准确建议生成的脚本人工审核后再执行。对于生产环境的变更一定要走正规的变更流程先在测试环境验证。6. 踩过的坑与对应的解决思路6.1 字段类型映射不符合预期第一次用PDMan做数据库转换时我发现MySQL的TINYINT(1)被映射成了Oracle的NUMBER(3)而我希望它映射成NUMBER(1)。这是因为PDMan的类型映射规则是内置的不一定符合每个项目的习惯。解决办法是在设置里自定义类型映射。PDMan允许你修改映射规则把常用的类型对应关系调整成自己想要的。调整一次后续所有转换都会按新规则走。6.2 导出的DDL缺少索引和约束PDMan默认生成的DDL只包含建表语句索引和约束需要单独设置。如果建表时没在PDMan里定义索引导出的DDL里就不会有。这一点和PowerDesigner类似需要你在模型里显式定义。我的做法是建表时就把常用查询字段的索引一起定义好比如外键字段、状态字段、时间字段。定义索引时注意索引命名规范一般用idx_表名_字段名的格式。6.3 模型文件过大导致打开缓慢当表数量超过两三百张时PDMan打开模型会变慢。这是因为它要把整个JSON加载到内存并渲染。解决办法是拆分模型按业务域拆成多个模型文件每个文件管一部分表。拆分后单个文件小了打开速度会快很多。拆分模型带来的问题是跨模块的关联关系不好维护。我的处理方式是核心的、被多个模块引用的表放在一个基础模型里其他模块的模型引用它。虽然PDMan不直接支持跨文件引用但可以在文档层面标注清楚。6.4 中文名和注释的编码问题在Windows环境下如果模型文件用了非UTF-8编码保存导出的DDL里中文注释可能会乱码。PDMan默认用UTF-8但如果你用其他编辑器改过模型文件可能会改变编码。解决办法是统一用UTF-8编码并且在PDMan的设置里确认编码配置。如果已经出现乱码把模型文件用UTF-8重新保存一遍即可。7. 关于PDMan使用的一些个人体会用PDMan这两年多最大的感受是它把数据库建模这件事从少数人的专业工具变成了团队都能参与的工作。以前模型文件锁在一个人手里现在模型就在仓库里谁都能看、能改、能评审。这种透明性带来的协作效率提升比省下的授权费用更有价值。当然它也不是没有短板。比如界面交互相比商业软件还有差距某些操作路径比较绕文档导出的样式定制能力有限想要特别精美的文档还得手工调整数据库同步功能不够智能复杂变更还是得手工写脚本。但考虑到它是开源免费的这些不足完全可以接受。如果你现在还在用商业建模软件而且团队有协作和版本管理的需求我建议花半天时间试试PDMan。从一个小的模块开始把模型建起来提交到Git感受一下diff的清晰度。用顺了之后再逐步把整个项目的模型迁过来。迁移过程不用急可以新旧并行一段时间确认没问题再完全切换。最后分享一个小技巧PDMan的模型文件里可以写备注我习惯在模型根节点加一个description字段记录这个模型的用途、负责人、最后更新时间。这样别人打开模型时第一眼就能知道这个模型是干什么的不用去翻文档。