1. 项目背景与工具选型思路1.1 为什么数据库建模阶段值得认真对待做后端开发这些年我见过太多团队在数据库设计上栽跟头。有的项目一上来就写建表SQL边写边改表结构随意加字段等业务跑起来之后发现数据关系乱成一团再回头梳理成本已经很高了。数据库表结构是一个系统最底层的地基地基没打稳上层业务代码再漂亮也没用。我接触PDManer也叫PDMan纯属偶然。当时在一个新项目里需要快速搭建一套包含几十张表的数据模型手头用过的工具各有各的别扭有些商业建模工具功能全但重授权成本也高有些在线工具用起来方便但表一多、关系一复杂就卡顿而且数据存在别人服务器上总有点不放心。朋友推荐了PDManer这个开源工具一试就用到了现在。PDManer本质上是一款国产开源的数据库建模工具定位非常明确把数据库表结构设计、ER图绘制、建表SQL生成、代码生成这几件事串成一条流水线。它支持MySQL、PostgreSQL、Oracle、SQL Server等主流数据库既可以反向从已有数据库导入表结构也可以正向从模型生成建表语句。最让我看重的一点是它生成的代码不只是模板拼接而是可以高度自定义的甚至有插件机制。这个工具解决的痛点其实很朴实不让数据库设计停留在文档或者某个人脑子里而是变成一个真正可编辑、可版本管理、可自动产出上下游产物的核心资产。无论是个人开发小项目还是团队协作的中大型系统建模这一步做得扎实后面写Mapper、写实体类、写接口文档的时候都会省下大量时间。1.2 PDManer 与市面上其他建模工具的区别很多朋友问我为什么不直接用Navicat或者MySQL Workbench画ER图呢我的看法是工具之间不是简单的谁替代谁而是看你在哪个阶段需要什么能力。Navicat这类数据库客户端核心是日常数据操作和管理它也有简单的模型设计功能但相对单薄。比如你要在一张表上配置一个枚举类型的说明、一个默认值的表达式、一个字段的“是否主键/唯一/自增”组合规则操作路径并不顺畅。更重要的是Navicat是付费商业软件团队全员安装授权是一笔不小的开销。MySQL Workbench免费建模能力也不错但如果你用的是PostgreSQL或者国产数据库它就没那么通用了。而且它的模型文件.mwb是二进制格式团队成员之间做代码评审、模型对比非常困难文件多版本冲突时几乎无法合并。PDManer的模型文件是json格式这点非常贴合开发者的习惯。JSON天然适合做版本管理Git里可以逐行追踪模型字段的变更历史这对我来说是刚需。另一个让我放心的点是它是本地应用模型数据存在自己的项目目录里不依赖云端对数据安全要求高的项目尤其友好。在建模能力上PDManer提供了完善的逻辑模型和物理模型支持、索引/约束/默认值/注释等完整字段属性配置、ER图自动布局和手动调整、版本间的模型对比与升级脚本生成这些功能覆盖了我在全流程建模中的绝大部分需求。配合代码生成功能基本可以做到“模型一改实体类、Mapper、XML、Service等代码同步更新”非常顺手。2. 建模核心流程拆解与实操要点2.1 从需求到数据模型的思考路径拿到需求之后我不建议立刻打开工具画表。建模的第一课是“先思考后建模”。我自己习惯按三步走先梳理业务实体再确定实体间关系最后落字段明细。业务实体怎么找很简单看业务描述里的名词。比如“用户”“订单”“商品”“支付记录”——这些名词大概率是核心实体。名词找出来之后再想想哪些是真正的核心实体哪些只是某个实体的属性。比如“收货地址”最初看起来像是一个独立实体但如果你细想一个用户可能有多个地址而且地址在订单里是快照式的存在下单时的地址不能被后续修改影响那么它就应该拆成独立表。这一类的判断直接决定了模型的结构是否合理。实体之间关系我用最朴素的方式画一对一、一对多、多对多。在PDManer里我通常先把多对多关系拆成中间表这样后续生成的SQL和ORM映射都会简单很多。比如“用户”和“角色”是多对多我会创建一个“用户角色关联表”里面放用户ID和角色ID再附上创建时间之类的审计字段。字段明细设计时我习惯给自己列几条硬性规则每个实体必须有主键主键尽量用自增ID或用雪花ID这类分布式ID不要用业务字段当主键。所有表必须有创建时间、更新时间这两个字段在排查数据问题和做增量同步时太重要了。金额、数量等数值字段一定要先搞清精度要求用DECIMAL而不是FLOAT/DOUBLE避免浮点误差。状态字段要单独拎出来想清楚状态的取值集合是什么、谁负责流转、要不要记录历史轨迹。这些规则看起来基础但实际项目中因为违反它们而返工的例子比比皆是。树形结构没设计好、枚举值直接魔法数字写死在代码里、软删除字段类型不统一……这些坑在建模阶段就可以规避掉大部分。2.2 实体、字段、关系设计的关键细节在PDManer里新建一个数据表界面不会给你压力但你要在里面填的东西值得认真对待。字段设计页里我看到很多初学者只填字段名和类型就完了。真正合理的做法是每个字段都要写“注释”。这个注释不是给数据库看的是给半年后的自己和团队同事看的。比如一个字段名叫status如果不写注释没人知道0、1、2分别代表什么写了“状态0-待支付 1-已支付 2-已取消”后面写代码和查数据都会舒服很多。PDManer生成的建表语句中注释会完整保留成SQL里的COMMENT直接同步到数据库这个习惯受益无穷。类型选择上不同数据库差异很大。PDManer里可以选择对应的数据库类型它会给出符合该数据库语法的字段类型列表。比如在MySQL里用DATETIME在PostgreSQL里用TIMESTAMP在SQL Server里用DATETIME2这些细微差异工具会帮你兜底。但你要理解背后逻辑时间字段如果涉及跨时区业务最好统一存UTC并在应用层转换如果只是本地单时区业务用数据库本地时间即可。关系的设计在PDManer里通过“外键”体现。但我建议逻辑上要有关系物理上建不建外键约束视情况而定。在互联网高并发场景物理外键会影响写入性能而且一旦数据量大后维护困难。所以我在PDManer里会明确画出关系连线但生成SQL时经常选择“外键只体现在关系图中不实际生成外键约束”。这个取舍我在后面生成SQL的章节还会详细说。索引设计是建模中很容易被忽略但极其影响查询性能的一环。PDManer中每张表都可以单独配置索引包括普通索引、唯一索引、组合索引。我自己的原则是唯一约束尽量用唯一索引表达组合索引要遵循“最左前缀”原则把区分度高的字段放前面把范围查询字段放最后避免每个字段都加索引因为索引不是免费的写入时要更新索引B树索引过多会拖慢写入速度。2.3 数据类型与命名规范踩坑基础命名规范是我在建模时最坚持的一件事。表名、字段名的风格统一会让后续所有环节SQL编写、ORM映射、代码生成顺利很多。我推荐这套规则库名、表名、字段名一律小写单词间用下划线分隔不混用驼峰。表名用业务模块前缀比如订单模块的表以ord_开头用户模块以usr_开头一眼能看出归属。字段名避免使用数据库保留字。order、user、desc、level这类词在MySQL 8中会带来意想不到的麻烦如果实在躲不开至少要用反引号兜底但最好前期就改名比如订单表叫ord_order订单状态字段叫ord_status。主键固定叫id关联字段用xxx_id格式比如user_id、order_id这样ORM映射时无需额外配置也能猜出大半。数据类型那边我再提一个容易踩的坑文本字段长度。很多人图省事对所有文本字段统一用TEXT或者VARCHAR(255)。这带来的直接问题是索引失效——MySQL里TEXT类型不能直接在非前缀索引下用VARCHAR(255)又浪费空间且可能超出索引限制。我的建议是状态码、短标识用VARCHAR(32)名称类用VARCHAR(64)或VARCHAR(128)备注类说明用VARCHAR(500)真正超长内容才用TEXT。PDManer里字段长度直接可配顺手填一下而已别偷懒。3. 实战用 PDManer 完成一套订单系统建模3.1 创建项目与数据源配置光讲理论不过瘾我拿一个实际的小型订单系统来演示完整建模过程。这套系统不用太复杂但典型场景要覆盖到用户、商品、订单、支付、售后再加一张审计日志表一共六张表足够说明问题。打开PDManer第一步新建项目。项目名称填“order-system”技术类型选择“MySQL 8.x”PDManer会自动按MySQL 8的方言处理后面的SQL生成。这里有个细节技术类型尽量一次性选对虽然中间可以改但改完之后字段类型映射可能会需要手动调整。项目创建后左侧会出现一个层级树包/模块下面的数据表列表。PDManer里的“模块”概念非常好用比如我可以建“用户模块”“订单模块”“商品模块”三个包把对应表拖进去模型文件大了以后找表就不用滚动了。数据源配置这块PDManer支持从已有数据库反向同步表结构。如果你手上是已有项目就可以通过“从数据库导入”直接生成模型。操作路径是右侧工具栏找到“从数据库导入”填上数据库连接信息勾选要导入的表PDManer会读取表结构、索引、注释自动生成对应的模型。我做老项目维护时经常用这个功能省去了手动录表结构的大量时间。3.2 核心表结构设计实操我会在“用户模块”下新建表。PDManer建表流程非常直接输入表名usr_user、表注释“用户表”然后开始加字段。用户表我会这样设计idBIGINT主键自增注释“用户ID”usernameVARCHAR(50)唯一索引注释“登录名”password_hashVARCHAR(64)注释“密码哈希值”nicknameVARCHAR(50)注释“昵称”phoneVARCHAR(20)可空注释“手机号”emailVARCHAR(100)可空注释“邮箱”statusTINYINT默认值1注释“状态0-禁用 1-正常”created_atDATETIME默认值CURRENT_TIMESTAMP注释“创建时间”updated_atDATETIME默认值CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP注释“更新时间”字段填写时留意PDManer的“默认值”输入框。它不只是一个文本箱你填CURRENT_TIMESTAMP生成SQL时就会原样输出如果填一个普通字符串工具会自动按数据库类型加引号这个细节能避免很多默认值生成的语法错误。订单表ord_order是核心中的核心字段会比用户表多。我给出几个关键字段及设计考量order_noVARCHAR(64)唯一索引注释“订单编号”。订单编号作为业务标识必须唯一但不要做主键因为即便用了雪花ID也不排除用户服务按单号查询给它加唯一索引就够了。user_idBIGINT注释“下单用户ID”。这里就是一对多关系的外键字段我在设计层面建立到usr_user.id的关系连线但生成SQL时不一定生成物理外键约束。total_amountDECIMAL(10,2)注释“订单总金额”。金额用DECIMAL而不用FLOAT。pay_statusTINYINT注释“支付状态0-未支付 1-已支付 2-已退款”ship_statusTINYINT注释“发货状态0-未发货 1-已发货 2-已签收”address_snapshotTEXT可空注释“收货地址快照JSON格式”。这是快照设计下单时把地址和商品信息沉到订单里避免后续地址变更影响历史订单。商品表prd_product、支付表pay_payment、售后表aftersale_log、操作日志表sys_audit_log也照此设计。整个建模过程中我一边建表一边通过ER图查看关系连线是否正确PDManer的ER图可以手动拖拽排列我习惯把核心表放中间关联表放四周一眼看过去清晰明了。3.3 关系图与逻辑校验表建完之后PDManer的“关系图”功能就可以派上用场了。关系图就是ER图的动态版本你可以在画布上拖拽表、连线、分组。画布上双击表还能直接跳到字段编辑修改字段之后关系图实时刷新。建立外键关系的操作是从表A的字段拖到表B的字段比如从ord_order.user_id拖到usr_user.idPDManer会自动识别关联并弹窗让你确认关系类型。这时候要注意一个细节关系类型要选“多对一”还是“一对多”它会影响后续生成代码时嵌套对象的生成顺序。从订单到用户是多对一从用户到订单是一对多。如果搞反了生成的Java实体类可能就是订单列表里嵌套用户列表完全不符合业务直觉。逻辑校验是很多用户忽略的功能。PDManer菜单里有“检查模型”之类的能力我建议在建模收尾时跑一遍。它能检查出主键缺失、字段名重复、关系引用不存在的表等问题。虽然不能保证模型100%合理但至少把低级错误挡在生成SQL之前。我每次建模结束都会跑一次校验心里才有底去生成脚本。3.4 生成建表语句的三种方式PDManer生成建表SQL有三种方式我分别说下适用场景。第一种是单表生成。在表节点上右键选择“生成SQL”或者“查看SQL”只输出当前这张表的建表语句。适合快速查看某一两表的结构不用把全部表的结构都刷出来。第二种是整库生成。选中项目根节点右键生成会把所有表、索引、注释、外键约束全部输出到一个SQL文件里。适合初始化数据库。这里可以选择是否包含“建库语句”、“DROP TABLE IF EXISTS”、“外键约束”等选项。我强烈建议只在初始化脚本里包含DROP语句稍后单独维护的增量脚本千万不要执行DROP否则线上数据直接没了。第三种是版本间差异生成。如果你修改了模型PDManer可以和上一个版本对比只生成增删改的SQL。这个功能在线上环境表结构升级时非常关键。它的操作在“版本管理”里确定旧版本和当前版本后工具会自动分析出新增表、新增字段、修改字段、删除字段并生成对应的ALTER语句。我用它来生成迁移脚本比手写ALTER靠谱得多。生成SQL前有几个选项值得留意“包含外键约束”如果生产环境性能吃紧或者你根本不想在数据库层面用外键就取消勾选关系只是模型层的逻辑关系不会落到物理外键。“生成注释”保持勾选字段注释会作为SQL注释输出而且是带COMMENT语法的对后来接手的人特别友好。“格式化SQL”PDManer默认生成的SQL就挺规范但不同版本可能有细微差异建议保留这个选项输出的SQL要能直接在Navicat或者命令行工具里跑通。生成的SQL示例长这样MySQL方言CREATE TABLE ord_order ( id bigint NOT NULL AUTO_INCREMENT COMMENT 订单ID, order_no varchar(64) NOT NULL COMMENT 订单编号, user_id bigint NOT NULL COMMENT 下单用户ID, total_amount decimal(10,2) NOT NULL COMMENT 订单总金额, pay_status tinyint NOT NULL COMMENT 支付状态0-未支付 1-已支付 2-已退款, ship_status tinyint NOT NULL COMMENT 发货状态0-未发货 1-已发货 2-已签收, address_snapshot text COMMENT 收货地址快照JSON格式, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, updated_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT 更新时间, PRIMARY KEY (id), UNIQUE KEY uk_order_no (order_no), KEY idx_user_id (user_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT订单表;这段SQL直接扔进数据库就能执行。表名、字段名、注释、索引、字符集全都齐了基本不用二次修改。4. 代码生成模块的完整落地4.1 模板配置与通用代码生成模型建好只是第一步真正让PDManer高效的时刻是从模型直接生成代码。它内置了代码生成引擎可以根据表结构自动生成实体类、Mapper接口、Mapper XML、Service、Controller等常见代码。这个功能背后其实是一套模板系统默认模板覆盖了Java MyBatis这套常见组合也支持自定义模板意味着你可以按自己的技术栈生成任何文本文件。第一次打开代码生成功能时左侧会让你选择数据库表右侧是模板列表。PDManer预置了一些模板比如一个“MyBatis3”模板它会针对每张表生成对应的DO类、Mapper接口和XML文件。你还可以选择生成到哪个目录以及包名、基础路径等参数。这里要给新手一个减负提示默认模板生成的代码只能算“骨架”别期待它一步到位生成无敌业务逻辑。它的价值在于你不再需要手写那些繁琐又雷同的实体属性和CURD基础方法而是可以把精力集中到真正的业务实现上。比如表里字段是user_id生成的实体类属性会自动变成userId类型自动对应Java类型的Long和String空值策略、注释都对得整整齐齐。对我来说省掉最烦的部分才是关键。4.2 自定义模板改造PDManer的代码生成真正拉开差距的地方是“自定义模板”。默认模板未必匹配你团队的技术栈比如你们用的是MyBatis-Plus或者JPA甚至用了自研的ORM框架。这些情况下你要学会写模板。PDManer的模板语法很像FreeMarker用${表名}、${字段名}这类占位符引用模型信息。你可以在“代码生成”面板里新建模板然后定义输出文件的类型Java文件、XML文件、文本文件、文件后缀、内容模板。模板里可以遍历当前表的字段列表、主键字段、关系字段等。我举个例子。假设团队要求所有实体类继承一个BaseEntity并且Swagger注解必须写到每个字段上。默认模板没有这个逻辑我就自己写一段package ${packageName}.entity; import io.swagger.annotations.ApiModelProperty; import lombok.Data; import java.time.LocalDateTime; Data public class ${tableNameCamelCase} extends BaseEntity { private static final long serialVersionUID 1L; #list table.columns as column ApiModelProperty(value ${column.comment}) private ${column.javaType} ${column.javaFieldName}; /#list }简单解释一下${packageName}是包名${tableNameCamelCase}是表名转成的驼峰类名table.columns是字段列表column.comment、column.javaType、column.javaFieldName分别是字段注释、Java类型、驼峰属性名。有了这个模板下次再建表生成实体类时Swagger注解、Lombok注解、继承父类全都自动带上团队规范就通过模板固化下来了。自定义模板还有个妙用生成前端代码。我们团队前端用的Vue Element UI列表页、表单页其实非常套路化。我写了一个模板把表字段自动映射成Form表单的el-form-item再配上字段必填校验、输入框、下拉框。模型一变前端表单CRUD页也几乎同时变。这在项目快速迭代期尤其爽前后端联调基本不会因为字段对齐问题反复扯皮。4.3 增量更新与版本管理代码生成的另一个痛点是怎么做增量更新。很多人担心模型字段改了生成代码会不会把之前手写的业务逻辑覆盖掉这个担忧合理但要看你怎么用。我自己的策略是把生成目录和手写目录分开。比如生成的实体类放在entity/generated目录手写的扩展类放在entity/ext目录。生成的实体类严格只包含字段和getter/setter手写业务放扩展类里这样重新生成时删除generated目录再生成即可不会破坏任何手写代码。版本管理维度PDManer的模型文件是JSON天然适合Git。我会把模型文件提交到代码仓库放在docs/database-model目录下每次字段变更都带上模型文件的修改记录。团队成员拉下来后用PDManer打开可以看到最新表结构。相比传统方式——靠口头传达“数据库我加了个字段”——这种把模型当代码一样做版本管理的方式信息断层和沟通成本都大大降低。模型文件里还隐藏了很多元数据比如字段顺序、注释、关系连线。这些元数据通过Git diff能看到非常清爽的变更记录代码评审时我看模型PR比看SQL脚本PR更直观因为模型文件不会出现“某人手滑改错了个别字段名”这种低级问题。5. 常见问题与排查技巧实录5.1 连接数据库失败PDManer“从数据库导入”或者“同步数据库”时连接不上这是最高频的问题我自己也踩过。排查顺序建议这样来第一确认数据库地址、端口、用户名、密码是否正确。尤其是密码里有特殊字符时比如、#要在连接串里转义或者在PDManer弹窗中直接原样填不要先复制到文本编辑器再粘贴有时编辑器会自动把特殊字符转换成全角那必挂。第二确认数据库是否允许外部连接。MySQL默认只监听localhost你要确保有远程访问权限或者你就在数据库本机用PDManer连接。检查方法是在数据库机器上执行连接测试排除端口被防火墙拦截的情况。第三确认驱动是否正确。PDManer内置了各数据库的驱动但如果你连的是某些国产数据库很多兼容MySQL协议但实际端口不同需要手动添加驱动。比如人大金仓的默认端口是54321PostgreSQL的驱动并不一定能识别它。在PDManer的设置里可以手动上传JDBC驱动jar包这一步需要提前准备。5.2 生成SQL在特定数据库报错同一个模型MySQL下完美生成切到Oracle或者PostgreSQL就报错这种问题我遇到不止一次。常见原因有两个字段类型映射不完整以及默认值写法不兼容。字段类型方面PDManer的技术类型切换之后字段类型映射表不一定完全覆盖你已有的类型。例如TINYINT在Oracle里不存在它可能映射成NUMBER(3)但如果字段长度设置得不对生成的NUMBER精度可能和你预期不符。解决方法是切技术类型后逐字段检查一遍类型映射尤其是日期、布尔、大文本、金额这几类。默认值写法在不同数据库差异巨大。最常见的是布尔类型MySQL里可以用DEFAULT b0或DEFAULT 0但在PostgreSQL里布尔量词是TRUE/FALSESQL Server里又不一样。PDManer在切换类型后一般会自动修正显式表达式但如果你在默认值里手写了函数比如CURRENT_TIMESTAMP在Oracle里是不存在的Oracle要用SYSTIMESTAMP或触发器。这类问题只能人工关注工具不会替你决策。我的建议是从一开始就确定目标数据库不要试图做一个“全数据库通用模型”。如果确实要支持多数据库在模型里用标准的、各库兼容度高的功能子集比如时间默认值统一在应用层或建表后再处理不依赖数据库侧默认值。5.3 外键关系生成错误关系连线画了生成的SQL里外键却对不上这也是个常见情况。表现形式有几种外键引用的表还没创建、外键字段和主键字段类型不一致、外键名重复。第一种情况比较好排查生成SQL时会按依赖顺序输出建表语句但如果你有两个表互相引用循环依赖PDManer生成时可能选择一个保守的顺序结果就是先建的表引用后建的表数据库直接报错。解决方法是在模型里尽量避免循环依赖真避免不了就用逻辑外键不加物理约束。第二种情况非常隐蔽关系连线的两个字段肉眼看着都是id但一个是BIGINT一个是INT数据库不允许这种外键约束。我记得有一次排查了很久最后发现是同事把订单表的user_id建成了INT用户表主键却是BIGINT。这里没有捷径只能逐个关系核对字段类型。第三种情况一般出现在你复制表后忘了改外键名。PDManer里外键名默认是fk_表名_关联表名之类复制粘贴新表后外键名会冲突。生成SQL时数据库提示“Duplicate foreign key name”这时候去关系图里检查一下把重复名字改掉即可。5.4 代码生成乱码与模板问题Windows环境下PDManer生成的Java文件偶尔会出现中文乱码文件内容看着就是一堆问号。这个大概率是文件编码问题。PDManer默认使用UTF-8但Windows控制台或者你打开文件的编辑器用了GBK。解决方法有两步第一步在PDManer的代码生成设置里检查输出文件字符集确保是UTF-8第二步用VS Code或IDEA打开生成文件时右下角切换文件编码到UTF-8。如果还是乱码用Notepad打开后另存为UTF-8。模板问题更多是语法上的。模板写错时PDManer一般会给出错误提示但提示信息不够直观。我的经验是先用最小可用的模板跑通再逐步叠加复杂语法。比如先只输出${tableNameCamelCase}这个变量确认能拿到值再尝试遍历字段。每次只改一点点出问题也知道是哪里改错了。5.5 团队协作中的模型同步多人同时编辑同一个PDManer模型文件合并冲突在所难免。因为模型文件是JSON虽然可以用Git处理但一个字段改动可能引起JSON大段重排导致合并冲突看起来非常吓人。我摸索下来比较好用的协作方式是这样的项目模型拆分成多个文件。PDManer支持“模块”概念每个模块可以单独导入导出模型文件。我的建议是大项目按业务域拆文件每个业务域一个模型文件避免所有人在同一个文件里挣扎。建表的负责人要明确。一张表尽量只有一个人负责设计其他人有需求走评审不要同时开两个人去改同一张表。利用PDManer的“模型对比/合并”能力。如果有两个人确实改到了同一文件可以从Git拉取后把对方的模型文件导入当前项目用对比功能查看差异再决定如何合并。这比直接打开文件乱改要安全得多。6. 实用心得与效率技巧6.1 我日常建模的推荐工作流用了很长时间PDManer之后我总结了一套稳定的工作流分享给想要上手的读者参考。第一步新建项目选好目标数据库类型。哪怕只是先试试这个选择也尽量定准因为后续字段类型映射都以它为基准。第二步边查需求边建表。我习惯先从核心实体开始比如订单系统的订单表、用户系统的用户表先把主链路各表建齐再去补辅助表和字典表。每建一张表就把字段注释写全不偷懒。第三步画关系连线跑模型校验。关系连线一定在表全部建完之后统一画不要在每张表建好就急着连否则中间改表名、字段名时连线容易断掉或者指向旧字段。第四步生成SQL在本地环境执行一遍。建表SQL生成后我在本地数据库执行一次确认所有表都能创建成功。这一步能提前暴露类型映射、默认值语法、字符集问题。第五步配置和微调代码生成模板。把默认模板改成符合团队规范的自定义模板生成一批代码跑个测试确认链路通顺。第六步把模型文件提交到Git并在README或者文档里说明模型文件位置和修改规则。这套流程里最花时间的其实是第二步其余步骤都是机械式的快速操作。正确的前期设计能让你在后续开发阶段几乎不再回头改表。6.2 模型文档自动化的延伸用法PDManer本身能生成数据字典文档。菜单里“导出文档”或者“生成数据字典”可以把模型输出成HTML或Markdown格式表字段列表、类型、注释、索引、外键关系一目了然。以前给客户或者团队写数据字典文档纯靠人工排版现在模型一改文档重新导出一遍就行零维护成本。我还会把生成的Markdown数据字典直接扔进项目的GitHub仓库里作为技术文档的一部分。这样不仅是开发人员测试、产品甚至运维都能随时查阅表结构不用专门去问开发“某字段是什么意思”。这种透明度在团队协作中价值很大也减少了那些“你帮我看看订单表这字段能不能存空值”的重复询问。再进阶一点的使用方式把PDManer模型和接口文档打通。比如给某张表生成Controller和Swagger注解接口入参出参直接从实体类反射生成字段注释就来自模型里写的comment。这样前端同事拿到的接口文档里每个字段的中文含义都是准确的不会出现代码和文档对不上的情况。6.3 几个容易忽略却很好用的功能有几个PDManer的小功能属于“知道的人一直用不知道的人一直绕远路”的类型我说几个。一个是“字段分组”。当一张表字段非常多比如配置表、扩展信息表PDManer允许给字段加分组标签比如“基础信息”“业务信息”“审计信息”在字段列表里可以按分组折叠查看表结构就不会显得很乱。这个功能用于大型表非常舒服。另一个是“模型版本管理”。在菜单的版本相关功能里你可以保存当前模型快照之后任意改动都能和快照对比。我建表时如果拿不准某个设计方案会先存一下版本改一版对比看看不好就切回去。这种试错成本比手改SQL低太多了。还有“字段导入”。如果你有Excel或者Word格式的已有字段清单可以通过PDManer的导入功能直接生成表结构字段名、类型、注释从表格里读取。以前从旧项目迁移表结构时我拿Excel列字段清单给客户确认确认完直接导入建模非常高效。这个功能容易被忽略但实际使用体验非常爽。最后还有一个经常被人忽略的点PDManer的项目文件里其实可以写“项目备注/说明”。我习惯在项目说明里记录建模约定比如“状态字段用TINYINT不使用INT”“所有表必须有created_at和updated_at”“金额统一DECIMAL(10,2)”等。新同事加入时打开模型文件就能看到这些约定比翻文档高效得多。数据库建模这件事工具只是手段关键是建模思路和团队规范。PDManer的魅力就在于它把这些软性的规范通过模板、模型文件、文档导出固化成了可以复制、可以传承的东西。我用这套方法完成了好几个项目的数据库设计和代码生成节省的时间非常可观而且模型的演进历史清清楚楚什么时候加了字段、为什么加了索引都能从Git提交记录里回溯。如果你还没试过用PDManer管理数据库模型下一次新建项目时不妨从一张订单表开始体验一下完整的建模到生成链路。