简介面向数据库设计初学者与开发人员的一份文档资料系统讲解概念模型、逻辑模型、物理模型的核心概念与相互区别并结合ERWIN、PowerDesigner两款常用建模工具梳理从概念到逻辑再到物理的完整设计路径。文中指出ERWIN主要提供逻辑模型与物理模型而PowerDesigner 15开始同时支持概念、逻辑、物理三种模型并给出实体、属性、关系、外键等对象的转换对照帮助理解不同模型的建模粒度。资源为单个Word文档约189KB内容涵盖模型种类说明、对象转换对照、工具常用操作及订单与产品关系示例目录结构清晰适合按章节查阅。已有182人浏览学习可作为数据库课程配套资料或系统设计参考。文档还重点辨析了概念模型与逻辑模型容易混淆之处阅读后能更快搭建数据库建模的整体框架。1. 数据库模型设计.doc这份文档背后是一整套让系统不返工的表结构方法论数据库模型设计.doc乍看是一个交付文档但在真实项目里它承载的是从业务需求到可落库表结构的完整翻译过程。很多团队把这件事简化成“画几张ER图、写一段建表SQL”结果上线三个月就开始被慢查询、字段对不上、改表迁移折磨到通宵。这个环节真正解决的是让一张订单表、一套用户体系、一份报表口径在写第一行业务代码之前就被定死不留糊涂账。适合谁适合那些被反复改表结构、跨系统字段对不齐、报表取数靠猜的开发者和刚带项目的技术负责人。这篇文章不堆理论直接讲清楚从概念模型到物理模型怎么走、DDL怎么写、范式怎么取舍以及一份能自动同步的数据库模型设计文档该怎么落地。2. 先说清楚三层模型概念、逻辑、物理各管哪一段画到哪层才算完很多开发第一次接触数据库模型设计是被要求“画个ER图”。但ER图只是表达形式真正决定交付质量的是你画的是哪一层模型。行业里通用的分层是概念模型CDM、逻辑模型LDM、物理模型PDM三层对应不同角色和不同颗粒度。最常见的翻车现场是产品拿概念模型当物理模型用开发拿物理模型当概念模型看两边对着同一张图吵半天最后发现说的根本不是一回事。2.1 概念模型只回答“业务里有哪些对象”一张图就够概念模型是给业务方和产品经理看的目标是确认业务实体和实体之间的粗粒度关系。它不关心字段类型、不关心主键策略甚至不关心表名怎么取。比如“用户”“订单”“商品”“支付单”加上它们之间的连线标注“1对多”“多对多”这一层就完成了。我在实际项目里这一层通常控制在半小时到一小时。做法是拉上产品、后端、前端各一个人在黑板上写实体名称然后用箭头连关系。这一层最重要的产出不是图本身而是把业务术语对齐——比如“订单”到底指下单行为还是指订单记录“客户”和“用户”是不是同一个东西。术语不统一后续逻辑模型写出来就是埋雷。概念模型画完要拿去给业务方签字确认这一步省掉后面改表就是无底洞。我见过一个项目概念模型阶段没确认“客户”和“联系人”是两个实体还是一个实体后端按两个实体设计了业务方其实默认是一个结果客户列表页的SQL绕了四张表性能怎么调都救不回来。2.2 逻辑模型的关键是属性与关系主键外键在这里定死逻辑模型开始进入数据结构层面每一张表要有明确的字段、字段类型、主键、外键、唯一约束。这一层不涉及具体的数据库产品也不涉及存储引擎、分区、索引这些物理实现。它的作用是让开发和DBA能坐下来评审这个字段是必须的吗这个关系用外键表达还是用关联表表达状态的取值范围是什么这一层最考验基本功的是关系基数判断。一对多好办多对多要拆中间表这个大家都有共识。容易出错的是“一对多”和“多对多”的判断标准。我常用的判断方法是问一句业务问题如果一条A记录永远只对应一条B记录那就是一对一如果一条A记录能对应多条B、但一条B只能对应一条A那是一对多如果两边都能对应多条那一定是多对多需要中间表。最典型的翻车案例是把“一个用户有多个收货地址一个地址只属于一个用户”建模成多对多硬拆了一张地址关联表导致后面所有查询都要多join一层。逻辑模型评审时我会拿着实体清单逐个问这个问题能省掉后面大量重构。这一层还有一个容易被忽略的点字段命名规范要在逻辑模型阶段就定下来。比如用户ID统一叫user_id还是uid创建时间统一叫created_at还是create_time状态字段统一叫status还是state。命名不统一是报表取数最大的坑我后面避坑章节会专门展开。这一层做完理论上写DDL只是翻译工作。2.3 物理模型才是能交给DBA的东西存储、索引、分区都在这层物理模型是在逻辑模型基础上结合具体数据库产品做适配。同样的逻辑模型MySQL、PostgreSQL、Oracle 落地出来的物理模型可能差异很大。比如 MySQL 的 InnoDB 表要定字符集、定引擎、定自增主键策略PostgreSQL 可能要处理序列Oracle 要考虑表空间。这一层还包括索引设计、分区策略、大字段拆分决策。我在做物理模型时会额外关注三件事。第一字符集MySQL 8.0 默认 utf8mb4但如果你的表有 emoji 存储需求必须在建表时显式指定否则线上改字符集要锁表代价极高。第二主键类型自增ID很多人在用但分库分表场景下要换成雪花ID或UUID不能等到拆库那天才来改主键。第三查询模式逻辑模型里不关心查询物理模型必须关心。比如订单表的 status 字段如果业务里经常按 status created_at 做范围查询物理模型上就要建联合索引。物理模型完成后应该能直接产出可执行的 DDL 和一份字段清单。很多团队在这一层偷懒直接在 Navicat 里右键建表靠手点而不是走脚本管理后面环境同步全靠手动导结构这属于给自己挖坑。我一般会把物理模型固化成一整套 DDL 脚本纳入版本管理每个环境用脚本同步而不是靠导出再导入。下面这张表是我常用三层模型对应产物的梳理模型层级主要读者核心产物关键决策点概念模型 CDM产品、业务方实体关系草图实体有哪些、关系是几对几、术语口径统一逻辑模型 LDM开发、DBA字段级表结构文档字段、主外键、约束、数据类型、命名规范物理模型 PDMDBA、后端DDL脚本、索引、分区方案存储引擎、字符集、主键策略、索引设计物理模型落地成 DDL 的时候有一个容易忽略的细节逻辑模型里外键用逻辑外键还是物理外键必须在物理模型阶段决策。很多人为了省事不建物理外键只靠程序保证一致性这在初期没问题但一旦出现脏数据排查成本很高。我会用物理外键但线上不加索引导致父表删除时全表扫描的问题要提前预料到外键列必须配合索引。3. 从业务描述到可执行DDL用一张订单表走通全部落地步骤理论层讲完进入动手环节。这一章用一个最常见的订单场景把实体识别、关系判断、字段设计、DDL 编写完整走一遍。订单系统是每个业务系统都绕不开的东西用它当例子最不容易产生理解偏差。我们假设需求描述是“用户在小程序上下单购买商品订单包含多个商品商品有价格和库存用户下单后生成一条订单记录记录包含用户信息、收货地址、商品明细和支付状态。”就这么一句话信息量足够建出核心表。3.1 实体识别从一段业务描述里抽出候选实体实体识别是数据库模型设计的第一步也是最容易被新手一带而过的一步。方法是把业务描述里的名词全部圈出来逐个判断它是实体、属性还是纯业务概念。这段话里的名词有用户、小程序、订单、商品、价格、库存、收货地址、支付状态。其中“价格”和“库存”属于商品的属性不是独立实体“支付状态”属于订单的属性“小程序”是渠道来源可以做成订单的一个来源字段不需要单独建表。那剩下的候选实体就是用户、订单、商品、收货地址。收货地址这里有个决策点它是挂在用户下的一个单独实体还是直接冗余进订单表如果业务里用户可以在多个地址里选择那地址应该独立成表用户和地址是一对多如果只是下单时临时填写的地址且历史订单要保留下单时的地址快照那订单表里直接存地址字段更合适独立一张地址表反而要处理地址变更对历史订单的影响。我的选择是地址独立表存用户常用地址订单表冗余一份下单时的地址快照。这个决策的原则是——主数据进表交易快照进订单。这个原则在后面范式章节还会展开。3.2 关系基数判断一对多、多对多别靠猜实体抽出来后第二步是确定关系基数。用户和订单是一对多这个没有争议。订单和商品是典型的“订单里可以选多个商品一个商品可以被多个订单购买”也就是多对多必须通过中间表表达。我把中间表命名为 order_item实际业务里它不只是关联表还承载了“下单数量”“下单时单价”“小计金额”这些明细级信息。基数判断的常见坑是把“订单和商品的多对多”误建模为“在订单表里加多个商品ID字段”。我见过有人把商品ID拼成逗号分隔字符串塞进订单表理由是“查询方便”结果是任何按商品维度的统计都得写 LIKE性能直接崩。正确做法是订单表和商品表各建主键中间表同时存订单ID和商品ID再附加明细字段。这里还有一个隐性决策order_item 表的主键是单独的自增ID还是用 order_id product_id 联合主键如果同一商品在同一个订单里只能出现一次不拆单合并联合主键是合理的如果允许同一商品出现多行比如分批发货就必须单独建自增主键。我一般选单独自增ID避免业务规则变化时受主键约束可扩展性更强。3.3 字段级设计数据类型、长度、默认值怎么定才不返工实体和关系定了最难的是字段级别设计。这一步决定了 DDL 怎么写也是后面返工最频繁的地方。核心注意点有四个。第一主键字段用 BIGINT 而不是 INT很多业务上线几年后单表数据量奔着亿级去INT 会被打穿。第二金额字段不要用 FLOAT 或 DOUBLE用 DECIMAL(10,2) 或者更精确的 DECIMAL(12,4)浮点数算金额会发生精度漂移这在账务里是不可接受的。第三时间字段统一用 datetime 还是 timestamp 要一个项目里只选一种混用会导致 2038 年问题和跨时区混乱。第四所有字段都要有默认值和注释线上系统最怕那种 nullable 且无注释的字段谁都不敢动。订单和订单明细的DDL我按实际生产习惯写出来可以直接拿来当模板CREATE TABLE users ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 用户ID自增主键, mobile VARCHAR(20) NOT NULL COMMENT 手机号登录账号, nickname VARCHAR(64) NOT NULL DEFAULT COMMENT 昵称, status TINYINT NOT NULL DEFAULT 1 COMMENT 状态1-正常 0-禁用, 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_mobile (mobile) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci COMMENT用户表; CREATE TABLE orders ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 订单ID自增主键, order_no VARCHAR(32) NOT NULL COMMENT 业务订单号给用户看的, user_id BIGINT NOT NULL COMMENT 下单用户ID关联users.id, status TINYINT NOT NULL DEFAULT 0 COMMENT 订单状态0-待支付 1-已支付 2-已发货 3-已完成 4-已取消, total_amount DECIMAL(12,2) NOT NULL DEFAULT 0.00 COMMENT 订单总金额实付, receiver_name VARCHAR(64) NOT NULL COMMENT 收货人姓名快照, receiver_mobile VARCHAR(20) NOT NULL COMMENT 收货人手机号快照, receiver_address VARCHAR(255) NOT NULL COMMENT 收货地址快照, pay_at DATETIME DEFAULT NULL COMMENT 支付时间NULL表示未支付, 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_status_created (user_id, status, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci COMMENT订单主表; CREATE TABLE order_items ( id BIGINT NOT NULL AUTO_INCREMENT COMMENT 明细ID, order_id BIGINT NOT NULL COMMENT 订单ID关联orders.id, product_id BIGINT NOT NULL COMMENT 商品ID关联products.id, product_name VARCHAR(128) NOT NULL COMMENT 商品名称快照, product_price DECIMAL(12,2) NOT NULL COMMENT 下单时单价快照, quantity INT NOT NULL DEFAULT 1 COMMENT 购买数量, subtotal DECIMAL(12,2) NOT NULL COMMENT 小计金额 product_price * quantity, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT 创建时间, PRIMARY KEY (id), KEY idx_order_id (order_id), KEY idx_product_id (product_id) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COLLATEutf8mb4_unicode_ci COMMENT订单明细表;这段DDL的关键逻辑我逐条拆一下。users 表里 mobile 做了唯一索引这是登录场景的硬要求避免同一手机号注册多个账号。orders 表里业务单号 order_no 是给用户看的它适合做唯一索引但主键我仍然用自增ID因为订单表会有大量按 user_id 维度的分页查询自增主键的聚簇索引对写入更友好。订单状态 status 用 TINYINT 而不是字符串是因为字符串状态在业务代码里容易写出五花八门的变体用数字枚举加注释反而可控。orders 表里我冗余了收货人姓名、手机号、地址这对应前面说的“交易快照”策略——即使后来用户改了常用地址历史订单仍然留着下单那一刻的地址对售后和物流追溯至关重要。索引方面idx_user_status_created 是联合索引覆盖列表筛选最常见的场景按用户查订单、按状态筛、按时间排序。order_items 表里我在 order_id 和 product_id 上分别建单列索引是因为报表经常按商品维度聚合而订单详情页按 order_id 查明细两个维度都需要快速定位。DDL 写完之后不要急着上线先做一次自测。我会把这三张表放到一个测试库里手工插入模拟数据跑几个典型查询查一个用户最近三个月的订单列表、查某个商品的总销量、查一个订单的完整明细。如果这三个查询都能在索引上命中模型基本合格。如果某些查询走了全表扫描提前发现比上线后补救成本低一个数量级。4. 范式与反范式三范式不是教条“够用就好”才是生产准则数据库模型设计的理论章节里范式永远是被引用的最多的词。但一线干久了你会发现完全遵守第三范式的库经常跑不动报表而完全不管范式的库又埋了一堆数据一致性的雷。这一章我把三大范式逐条拆开讲清楚它们各自防的是什么问题再说什么时候主动打破它。4.1 三大范式逐条拆解第二范式为什么最容易被忽视第一范式要求字段不可再分。用大白话说就是一个字段不能存一个列表不能存逗号分隔的一串值。但是实践里有一条灰色地带——JSON字段。现代数据库比如 MySQL 5.7 以后都支持 JSON 类型很多人觉得用 JSON 存结构灵活也不违反第一范式。这个认知不全错但要区分场景。比如订单表里存一个“优惠明细”的 JSON记录用了哪几张券、每张券抵扣多少这个设计是合理的因为优惠明细不会单独作为查询条件。但如果你把商品的标签存成逗号分隔字符串还经常按标签筛选商品那就不仅违反第一范式还会让查询写出 LIKE %tag%索引全部失效。第一范式在落地时的判断标准很简单字段是不是需要被单独查询、单独计算需要就拆不需要才允许聚合存储。第二范式是“非主键字段必须完全依赖主键”它只出现在联合主键的场景里。我强调它容易被忽视是因为很多表根本不设计联合主键自然踩不到这个坑。但一旦你遇到关联表比如前面订单明细表如果用了 order_id product_id 做联合主键那么“商品价格”这种字段如果也被塞进这张表它就只依赖 product_id 而不依赖 order_id这就是部分依赖会造成同一商品的价格在多行里重复存储改价时要么漏改要么必须全表UPDATE。第二范式真正的价值是逼你审视联合主键下的字段归属每个字段必须问一句“它是不是依赖于整个主键”。如果答案是否定的这个字段应该挪到别处去。第三范式要求非主键字段之间不能有传递依赖说白了就是“字段不能通过另一个字段间接依赖主键”。经典的违反案例是订单表里存了 user_id又存了 user_name。user_name 其实是通过 user_id 关联出来的不是直接描述订单本身。这种冗余的危害在用户改名时会暴露——如果不同步更新历史订单的用户名就错了。第三范式在实现层的翻译是能通过关联查出来的信息不要在主表里重复冗余。我把三条范式的判断逻辑浓缩成一张自查表建模时拿它逐字段过一遍范式口语化判断违规的典型表现生产中的可接受度第一范式一个格子里有没有塞一列表的东西逗号分隔ID、JSON存列表且需要按元素筛选查询维度单一时可接受第二范式联合主键下字段是否只依赖部分键明细表里存了只依赖商品ID的字段几乎不可接受第三范式字段之间是否出现了间接依赖订单表里冗余了用户名、商品名视场景主动取舍4.2 反范式的三个典型场景冗余、预计算、宽表范式不是目的数据一致性才是目的。生产环境里主动违反范式的情况比教科书里写的还要常见。第一个典型场景就是我在订单表里做的快照冗余——把商品名称、价格冗余进订单明细表。商品的主数据比如当前价格会变但订单的历史金额、历史商品名必须锁定。这也是为什么即使第三范式说“不要冗余”做交易系统的团队也一定会快照。这个冗余不是设计缺陷是业务刚需。第二个场景是统计数据预计算。比如商品表里存一个 sales_count 累计销量字段每次下单就 UPDATE 这个字段这样商品列表页按销量排序时直接 ORDER BY sales_count不用去聚合几亿行的订单明细表。这违反了第三范式也引入了数据一致性问题比如订单取消时要回滚销量但你换回来的是在几百毫秒内响应用户这笔账大部分电商系统都算得过来。第三个场景是宽表。报表和数据仓库里经常把用户维度的几十个字段拼成一张大宽表反范式到了极致。因为报表查询的特征是多条件筛选、少更新用宽表牺牲更新一致性换查询性能。我在业务库做数据库模型设计时默认守住第二范式因为它的坑最隐蔽且后续修复成本极高第一范式看查询维度第三范式则完全看字段变更频率——主数据变更频繁、历史数据需要稳定就允许冗余快照。反范式落地时有一条铁律每做一处冗余必须同时写清楚同步更新机制。是事务里同步更新还是异步任务刷必须明确。没有同步机制的反范式就是给未来埋脏数据炸弹。我在订单表冗余地址快照的同时会在设计文档里注明用户修改常用地址时只改 address 表订单表冗余数据不做同步。这个决定是业务规则不是技术疏忽。5. 数据库模型设计避坑指南五个能让项目延期两周的设计错误数据库模型设计的坑大多不是不会写建表语句而是设计决策在早期看起来都对等到数据量上来、业务场景变复杂才爆雷。这一章我列五个我亲眼见过、亲手踩过的坑每条按现象、原因、解决三段式拆开。这些错误在评审阶段往往被当成“细节问题”放过但它们造成的返工量最重。5.1 用自增ID当主键没错错的是把业务号也当主键现象订单表以 order_no业务订单号作为主键自增ID作为普通字段。上线初期一切正常后来要做分库分表时发现无从下手——业务号没有规则无法通过它做数据路由。原因业务号是用户可见的业务概念它受业务规则影响比如不同渠道的订单号前缀不一样甚至可能被要求从特定数字段开始。用业务号做物理主键等于把存储实现和业务规则耦合在一起。解决主键必须是无意义的内部标识自增ID或雪花ID业务号单独建唯一索引保证不重复但永远不做主键。这也是我在第3章订单表设计里为什么 order_no 建了 unique index 但主键是自增 id 的原因。5.2 时间字段用datetime还是timestamp选错会在2038年翻车现象项目里既有 datetime 又有 timestamp某一天业务报错日志显示时间字段变成 1970 年或者 2038 年附近的值查数据发现把超出范围的时间存进去被截断成最大值。原因timestamp 在 MySQL 里的存储范围是 1970-01-01 到 2038-01-19它还受时区影响一旦服务器时区设置变更历史数据读出来就偏移了。而 datetime 的存储范围宽得多不随时区漂移。解决在一个项目里统一用 datetime如果确实需要区分时区用 datetime 加单独存储时区偏移量。特别是涉及预约、定时任务这类未来时间比较久的业务用 timestamp 基本属于定时炸弹。我在第3章的 DDL 里全部用 DATETIME这就是原因这不是个人偏好是拿 2038 年问题换来的教训。5.3 给所有列都建索引查询没变快还拖慢了写入现象开发为了方便把 where 条件里出现过的字段全建上了单列索引结果是有二十几个索引的表插入一条记录耗时反而比原来涨了一倍而且有些查询用了索引还是慢。原因索引不是免费的每建一个索引就多一份写入时的维护成本还占磁盘空间。更隐蔽的是查询优化器在一个表有多个单列索引时可能只选其中一个并不会自动合并你建了十个索引实际生效的可能就一个。解决索引设计从查询场景反推不要从字段反推。把高频查询的 where order by group by 组合起来分析让联合索引尽量覆盖组合条件而不是各建各的。我建索引前会先列一个查询清单按频率排序前三个高频查询决定了90%的索引设计。5.4 删除用物理DELETE丢了后悔药才想起需要逻辑删除现象订单表里有几条数据被误删等业务发现的时候binlog 已经过期数据找不回来只能让客户重新下单或者手动补单同事之间互相扯皮。原因团队在模型设计时没有统一约定删除策略开发随手写了 DELETE FROM orders WHERE id ?。物理删除不仅丢数据还会破坏订单明细关联的完整性统计数字也会对不上账。解决核心业务表统一加 is_deleted TINYINT 字段做逻辑删除默认 0删除时 UPDATE 置 1查询条件里强制带 is_deleted 0。这个字段一定要放进模型设计文档的公共字段规范里并让所有新增表默认带它。逻辑删除不是万能药数据量大了要处理唯一索引冲突删过的业务号再生成时可能撞索引但这属于可控成本物理删除的后果不可控。5.5 字段命名不统一报表SQL能写出三十种写法现象报表部门提数时发现“创建时间”在订单表里叫 created_at在用户表里叫 create_time在支付表里叫 pay_time 里的 time 字段光一个时间字段就三种叫法。按用户昵称字段也是有人写 nickname有人写 user_name。报表SQL写了三十种写法来兼容维护成本爆炸。原因模型设计阶段没有定命名规范每个人建表时按自己习惯来。这个坑的可怕之处在于它不是一次性爆发的而是每接一个报表需求就折磨一次。解决在数据库模型设计文档里固定一套命名字典——时间统一 createdAt/updatedAt 的蛇形写法 created_at、updated_at主键统一 id外键统一 实体_id状态统一 status。所有表必须遵守不进评审。命名规范是成本最低收益最高的设计决策它值得写进文档的第一页。6. 把模型文档做成能自动同步的活文档数据字典与ER图生成技巧标题里的 .doc 后缀提醒我一件事数据库模型设计文档如果只是建表时写一次然后躺在文件夹里吃灰它就没有任何价值。我现在的习惯是让文档跟着库结构走库结构变了文档自动变不给自己留手动同步的负担。这里分享一个最常用的自动化方案从数据库信息表反向生成数据字典。MySQL 的 information_schema 库里存了所有表结构的元数据我常用的生成语句是这样SELECT TABLE_NAME AS 表名, COLUMN_NAME AS 字段名, COLUMN_TYPE AS 字段类型, IS_NULLABLE AS 是否可空, COLUMN_DEFAULT AS 默认值, COLUMN_COMMENT AS 字段注释 FROM information_schema.COLUMNS WHERE TABLE_SCHEMA your_database_name ORDER BY TABLE_NAME, ORDINAL_POSITION;这段SQL能一次性导出整库所有字段的元数据把它们复制到 Excel 或直接转成 Markdown 表格就是一份数据字典。如果你用 Python加上 pandas 几行就能生成 Markdown 文件再复制进 Word 里作为“数据库模型设计.doc”核心章节。ER图生成也有个省事的办法用支持 DSL 建模的工具比如 dbdiagram.io 的语法用文本描述表结构然后一键导出图片。它的DSL写起来不复杂Table orders { id bigint [pk] order_no varchar(32) [unique] user_id bigint [ref: users.id] status tinyint created_at datetime } Table users { id bigint [pk] mobile varchar(20) [unique] }这种文本化的建模方式最大的好处是能进 Git表结构变更时 diff 非常清晰比在图形工具里手画图再截图放进文档要靠谱得多。我的习惯是每次表结构变更同步改 DSL 文件再重新生成ER图和数据字典整个流程控制在十分钟内。关于数据库模型设计这个方向最后一点个人经验模型设计的投入产出比在于前期多花一天评审能省下后期至少一周的返工。如果你还没把文档自动化可以从今天这段SQL开始第一次跑通之后你会爱上这种不用手工维护文档的感觉。希望帮到你。本文还有配套的精品资源点击获取