简介一份面向Oracle数据库设计人员与开发团队的规范文档旨在解决系统设计过程中数据模型不统一、命名混乱、字段类型随意等问题。文档系统梳理了数据库策略字段长度需结合业务、字符集与时间格式设定数据完整性应遵循第二范式并尽量满足第三范式减少外键与触发器OLTP与OLAP需分开设计后者可适当冗余以提升查询性能。命名规范覆盖数据库、表空间、表、字段、视图、序列、存储过程、函数、索引及约束并给出金额NUMBER(16,2)、税率NUMBER(10,6)、名称VARCHAR2(50)等常用字段定义建议。压缩包共1个doc文件约296KB结构清晰可直接作为团队设计标准参考。目前已有267人学习下载适合需要统一数据库设计规范的中大型系统研发团队使用。1. 8数据库设计规范.doc不用等别人催先搞清楚这份文档要锁死哪些东西项目文档里出现“8数据库设计规范.doc”这样的文件很多人第一眼会把它归类为“存档用的资料”。其实它的定位很明确这是团队约定好的建表规矩用来约束库、表、字段、索引、数据字典在设计和变更时怎么做。它要解决的不是“数据库基础知识”而是现实里最常见的一堆烂账——同一个库里 userId 和 user_id 混着写、金额字段有人用 float 有人用 decimal、状态字段光秃秃一个 int 连注释都没有、建表时没人写字段说明几个月后接手的同事对着线上库一脸懵。这份规范适合后端开发、DBA、以及准备启动新模块和重构老系统的人。读完你会知道它该管哪些事、怎么落地到评审流程而不是把它供在共享盘里吃灰。2. 库表命名、字段类型、公共字段这三个约定不写死后面全是口水仗数据库设计规范最容易犯的错是前面堆了一堆概念真到建表时却没有任何硬性结论。规范里的每一条都要让人能执行不能写“根据实际情况选择”。第一件要定死的就是库表命名、字段类型和公共字段。2.1 库名与表名把大小写和下划线习惯一次摁死库名和表名的统一看起来是小事实际上是后续所有工具链能跑顺的前提。见过不少团队因为表命名吃过亏开发在 Windows 上建的表是 UserAccount脚本提交到 Linux 测试库一执行直接报“表不存在”。原因就是 MySQL 的 lower_case_table_names 参数在 Linux 上默认区分大小写Windows 上默认不区分。你再写个 user_account和你建的 UserAccount 就不是一张表。Oracle、达梦数据库也有自己的一套不带双引号建表标识符会转成大写。所以最省事的方案是全部小写、下划线分词不依赖数据库的引用特性。我一般建议的规则是库名用 db_业务域表名用 模块名_业务名_子业务。举例来说用户模块的账户表就叫 user_account订单模块的明细表叫 order_item_detail。不要加 tbl_ 前缀不要用驼峰更不要用“yhzh”这种拼音缩写。下面这个表格可以作为规范附录直接复制业务模块库名表名前缀示例用户中心db_useruser_user_account、user_address订单交易db_orderorder_order_info、order_item_detail商品库存db_productproduct_product_sku、stock_record特别要写进规范的是“保留字清单”。很多订单系统的开发顺手就建一张 order 表但 order 在 MySQL、Oracle、达梦里都是排序关键字后续查询、分组、工具连接都可能出问题。与其冒险不如约定订单相关表一律用 biz_order 或 order_info。类似需要避开的还有 group、user、describe、level。把这些词直接列为禁用表名能少一堆麻烦。表名长度也要有约束建议不超过 32 个字符。达梦和 Oracle 对标识符长度有上限MySQL InnoDB 虽然允许 64但表名一长可读性会断崖式下降。超过 32 字符的命名往往是业务过程都堆在里面该考虑拆表了。索引和约束的命名同样要定规矩。非唯一索引用 idx_表名缩写_字段名唯一索引用 uk_表名缩写_字段名主键用 pk_表名。如果不用规范命名数据库自动生成的索引名往往会带随机后缀DBA 排查慢查询时看名字完全不知道它对应哪个字段效率就下来了。2.2 字段类型时间、金额、状态这类字段最容易互相抬杠字段类型是评审时争论最多的地方。规范的作用不是阻止争论而是给出结论让大家不用每次重新吵一遍。主键、时间、金额、状态是四个矛盾源头。主键字段统一推荐用 bigint 无符号自增MySQL 里写成 bigint unsigned达梦和 Oracle 用 NUMBER(19)。int 在数据量到千万级以后很容易撑不住重建主键又是一次大手术。UUID 不是不能用但规范里要限定使用场景分布式主数据合并、离线导入等有跨系统标识需求的场景才用并且不建议用 varchar(36) 存储最好换成二进制或雪花 ID。业务字段不要当主键尤其是身份证号、手机号这种可能变化或脱敏的字段。时间字段统一用 datetime 或 timestamp禁止用 varchar 存时间。早期见过一张流水表把时间存成 char(19)后来要按天做分区遇到 varchar 类型做范围条件非常麻烦查询也走不了好的索引。还要区分“创建时间”和“业务时间”比如订单的下单时间属于业务时间create_time 是数据落库时间两者不能混用一个字段。如果系统要跨时区规范里要明确使用 UTC 的 timestamp并且所有写入都转成同一时区不能靠客户端随意传。金额字段统一用 decimal。订单金额最低 decimal(18,2)汇率和更精细金额用 decimal(18,4)。float 和 double 必须禁止理由很直接二进制浮点无法精确表达十进制小数对账多跑几轮就知道误差有多恶心。状态字段建议要么用 varchar 存可读性强的枚举字符串比如 SUCCESS、FAILED要么用 tinyint 配数字但必须在字段注释里把所有取值写全。最怕的是 status 字段注释只写“状态”取值 0,1,2,9 完全没有解释历史数据一旦混进一个 status9代码和文档都无从查起。下面这张选型表可以贴在规范里字段场景推荐类型不推荐原因主键bigint / NUMBER(19)int、varchar(36)int 撑不到大数量varchar 主键占空间且散列不均时间datetime / timestampvarchar不能走时间分区格式难以统一金额decimalfloat、double二进制浮点有精度误差手机号/身份证varcharbigint可能有前导 0 和格式变化大文本text / clobvarchar(5000)超长 varchar 和 text 在实际存储上差异较大这里也顺带说了数据库优化的一个基本原理字段类型决定了索引的存储效率和比较成本。类型定得越短、越契合业务索引越紧凑扫描性能越好。规范里写一句“能用 varchar 别用 text能用 int 别用 varchar”就行但注意别极端该用 text 的地方也别硬塞进 varchar。2.3 公共字段每张业务表都要背的固定套装公共字段的作用是让每一张表在被排查时都有基本信息。我建议核心业务表至少包含七个字段id 主键、create_by、create_time、update_by、update_time、deleted 逻辑删除、version 版本号。流水表可以去掉 create_by 和 update_by但时间字段和版本号还是要保留。公共字段最容易被争论的是这些字段由数据库维护还是应用维护。我的观点很明确create_time 和 create_by 在 INSERT 时由应用传值update_time 和 update_by 在 UPDATE 时由应用统一赋值不要依赖数据库触发器或 ON UPDATE CURRENT_TIMESTAMP。触发器在建表脚本里隐藏得深数据库同步工具在同步结构时常常漏掉触发器最后线上行为完全对不上。ON UPDATE 的自动时间戳也有问题批量更新、软删操作时它未必能反映业务真正变化的时间。规范把这些边界写清楚代码层统一模板后续排查才有据可查。逻辑删除字段的写法要特别注意。很多人用 deleted tinyint default 0删了置 1问题是如果某张表有唯一约束比如手机号唯一软删一条记录后再次插入同一个手机号会被唯一索引挡住。稳妥做法是在规范里建议把“删除标记”做成可空时间戳 deleted_at未删除是 NULL删除时写当前时间。唯一索引在 MySQL 里允许多个 NULL所以不会拦住重复插入。如果团队不想改成时间戳也可以用 deleted 加全局唯一方案但要复杂些不建议新项目用。version 字段要配一条硬性规则涉及更新状态、扣减库存、账户余额这类操作UPDATE 必须带 where version 旧版本应用层读出来再回写否则两笔并发请求会把后提交的那次覆盖掉前一次。这跟数据库并发锁不完全是一回事数据库行锁能保证两条 UPDATE 不重叠但“先查询再更新”的间隙仍然会丢更新。规范里写上“禁止先 SELECT 再 UPDATE 的裸写法”很多并发问题能提前按死。3. 数据字典和表关系怎么写才不会跟代码走着走着就散了规范里如果只规定命名和类型那它只是半份文档。另一半是数据字典和表关系。许多团队的字典文档之所以没人更新是因为一开始的结构就错了。要把字典做成容易增量更新的形态而不是一篇长篇大论。3.1 数据字典最少拆成三张表表清单、字段清单、枚举清单数据库设计规范里的数据字典不要按表名写成一章一章的 Word。那样新增一列要翻半天目录最后一定没人维护。建议直接在文档里挂三张表用 Excel 或者 Markdown 表格都行。第一张是物理表清单记录表名、中文名、所属模块、负责人、状态。这张表用来做全库盘点哪些表在用、哪些是废弃表一目了然。第二张是字段清单每张表一行行列出字段名、类型、长度、可空、默认值、说明、关联字典编号。第三张是枚举清单把业务里的状态、类型、来源等枚举值集中管理包括枚举编号、取值、中文含义、生效状态。举个例子字段清单里 user_account.status 是 1对应枚举清单里字典编号 USER_STATUS 下取值为 ACTIVE 的含义是“启用”。如果以后要增加状态只改枚举清单这一行不需要去翻每一张表的数据字典。枚举值散落在各张表的注释里是最差的维护方式。有的开发会说“我在表注释里写清楚了呀”但注释能写进工具导出的建表脚本里却很难进到业务侧的逻辑判断里最后还是会各自为政。3.2 用数据库反向生成字典再人工补业务注释维护数据字典有个省力技巧不要从零手写先让工具帮你生成骨架再补业务信息。常见的做法是先用数据库连接工具把现有的表结构导出来比如 Navicat 连接 MySQL、达梦等数据库后选中表和模型右键“导出表结构”或“逆向数据库到模型”可以得到类型、长度、注释这些基本信息。然后把导出结果粘贴进字段清单 Excel 里由表负责人补充“业务含义”这一列。这里要提醒一点MySQL 的字段注释在工具里可能被截断所以字段说明这类信息要控制在 200 字符以内。更长的内容放到规范文档的字段清单说明列里。如果是达梦数据库通过 Navicat 连接需要配置好 ODBC 驱动导出时尽量选择“仅 DDL”模式避免把用户数据也带出来。如果老库已经建成又想快速盘点我建议用数据库同步工具辅助在测试环境建一个空的数据库把生产库结构同步过去再做一次结构 diff能自动列出哪些表没有注释、哪些表缺少公共字段。这一步虽然不能完全替代人工但可以节省大量翻表时间还能在重构前把家底盘清楚。3.3 表关系图画到能看着图写 SQL 的程度规范文档里的关系图不建议追求教科书级的实体关系建模更建议画一张开发真能用的物理关系图。概念图给业务看物理图给开发看。物理关系图上必须出现表名、字段名、主键、索引和外键关系。画图的最佳方式是从数据库逆向生成而不是手动画框。用 Navicat、DBeaver、PowerDesigner 的逆向功能先把库结构导成模型再手工调整关联关系这样图里的字段永远不会和线上脱节。这里要明确一下外键的处理原则。很多互联网团队明确不用物理外键理由是 OLTP 性能、分库分区后外键不可用、以及应用层补偿更好维护但一些传统企业项目要求必须定义外键来做约束。规范里必须二选一否则开发的表结构和 DBA 维护的 ER 图永远对不上。我一般建议单机事务型数据库核心业务可以用物理外键分布式、微服务、分库分表一律不用物理外键只保留逻辑外键并在字段说明里标注引用关系。关系图里还有一个细节一对多关系在多的一方保存主表 ID不要在主表里冗余一个“子表最新一条”的字段多对多关系必须拆中间表中间表名用 user_role、order_goods_rel 这样的结构。这些约定能让开发的 join 方向一致不会同一张中间表建出来三个版本。4. 从规范到建表流程模板、评审表、结构对比一个都不能少文档里写得再完善缺少流程约束也会逐渐失效。真正让数据库设计规范落地的是三样工具建表模板、评审表、结构对比动作。4.1 标准建表模板把注释、索引、约束一次写全规范里应该附带一个标准的建表模板让团队所有新表都从模板复制再改。模板的骨架要包含主键 id、公共字段、业务字段、所有字段注释、索引声明、存储引擎和字符集。在 MySQL 下存储引擎统一 InnoDB字符集统一 utf8mb4。达梦、Oracle 这类数据库则用库级默认字符集但注释和字段名规则不变。模板里还要规定索引的写法。建议单表索引数量不超过 5 个联合索引字段不要超过 3 个。为什么限制数量不是不让建索引而是不让开发在每个字段后面都跟一个单独索引这样看起来查询快实际上写操作和索引维护的成本会失控。更具体的做法是联合索引的字段顺序要和最常用的查询条件顺序一致例如 where order_id and product_id 就建 idx_order_product(order_id, product_id)而不是分别建两个单列索引。模板里的默认值要显式写全。很多开发建表时不写默认值让字段默认为 NULL但业务上其实不允许空值。规范应该写明数字统计字段默认 0布尔字段默认 0时间字段按是否业务必填决定默认 NULL 还是 CURRENT_TIMESTAMP。如果模板里每个字段都有 DEFAULT后期迁移到严格模式或做数据比对会省很多事。4.2 表结构评审检查表建表前过一遍少返工在表结构提交审核时直接附上一张检查清单效率远高于口头评审。参考下面的检查项检查维度检查内容表命名小写、下划线、无保留字表注释必须有中文注释字段注释每个字段必须有写明含义和单位字段类型金额用 decimal时间不用 varchar字符集统一 utf8mb4 或库级公共字段含 create_time、update_time、逻辑删除、版本号主键bigint/NUMBER(19)非业务字段索引索引名规范无冗余索引符合联合索引左前缀默认值每个字段显式 DEFAULT数据字典字段清单和枚举清单已同步更新这张检查表我在实际评审里用过最能拦住问题的其实是两行索引冗余和字段注释。注释缺失的字段线上排查时无法判断字段来源只能靠猜。索引冗余则会让慢日志里出现“using index for group by”却不知道哪个索引真正被用到。评审时不要只看建表语句能不能跑要对照检查表逐项勾选宁可多花两分钟也不要让问题进到测试环境再返工。4.3 通过结构对比治理“文档说一套、线上另一套”很多团队最后规范失效不是因为大家不遵守而是文档和线上库不再同步。治理这个问题要在发布流程里加一道结构对比。具体做法是在发版前先用数据库同步工具比较测试环境和生产环境的表结构。Navicat 的结构同步可以选出两个库然后只推送 DDL 差异还可以把差异 SQL 导出来当作发布说明的一部分。结构同步工具适合做 precheck但不建议直接把差异 DDL 往生产上推。生产库的结构变更最好通过评审过的脚本执行工具只用来发现问题。结构对比的触发时点也很重要。我一般会固定安排在每个迭代发版前的最后一天把测试库和生产库的差异导出来跟文档里的字段清单对照。如果发现生产库有字段而文档里没有说明上一次变更漏掉了文档更新这个“文档缺口”要作为这次发版的任务补上不能拖。这样坚持两个迭代团队就会慢慢形成“先改字典再改脚本最后执行建表”的习惯。如果项目已经进入稳定期还可以在技术上引入数据库迁移工具例如 Flyway 或 Liquibase把每次结构变更写成一个版本化脚本。规范里只要写一条“所有变更必须走迁移脚本禁止在客户端直接改表结构”这个动作就相当于给数据库变更加了版本管理。迁移工具在引入初期需要先把线上表结构导成 baseline 脚本这个 baseline 必须和生产一致否则之后执行迁移时会被工具误判为已变更这是前面最容易掉进去的坑。5. 避坑数据库设计规范最容易翻车的几个地方规范写得再完整也不代表一定能落地。下面这五个坑基本是我见过最多项目翻车的地方每个都是“现象-原因-解决”三个步骤能讲清楚的。5.1 坑一规则只停在 Word 里建表时该干嘛干嘛现象是规范发布后没人看开发到写表结构时依然按自己的习惯落库新表三天两头出现奇葩大小写和字段类型。原因是规范没有进入实际流程文档是静态的没有在提交动作前设置检查点。解决方法是把规范变成建表须知在建表工单的表单里内置命名、公共字段、检查表这些必填项。DBA 或架构师在审核 DDL 时直接拿检查表逐项打勾不合规的打回重提多卡几次大家就记住了。5.2 坑二用业务字段当主键最后还是自己打脸现象是用户表用身份证号做主键配置表用“配置编码”做主键等到业务规则变化或数据合并时才发现问题。原因是把业务唯一性和主键混为一谈。解决方法是规范里明确“主键必须是代理键”也就是无业务含义的自增或者雪花 ID业务唯一性通过唯一索引单独实现。如果老库已经用 varchar 业务字段做了主键不要硬删先增加新主键字段再迁移引用它的外键分步回填最后再取消老字段的主键约束。5.3 坑三状态字段是数字又没有枚举字典现象是 order_status 取值 0、1、2、9注释里只写了前三个后来新增的状态只能靠代码去猜。原因是枚举定义没有集中管理字段注释和文档更新不及时。解决方法是把状态字段的取值统一沉淀到枚举清单里字段注释里把当前所有枚举值写完整代码层用常量或枚举类型引用不允许在业务流程里直接写 magic number。如果历史数据里已经有脏值新代码要增加未知枚举值的兜底别用“else 都按已支付处理”这种写法。5.4 坑四过度范式化上线后性能翻车现象是业务表按第三范式拆成七八张从表查询时 join 一大串数据量过百万后接口响应从几百毫秒涨到几秒并发高一点还出现数据库死锁。原因是规范没有留“反范式”的口子开发把拆表当作唯一正确方案。解决方法是规范中增加“冗余字段允许原则”订单表可以冗余商品名、单价快照用户统计表可以冗余统计结果一致性通过业务代码或同步工具去维护。评审时看到超过五张表 join 的查询拦截下来问一句“这个冗余字段是不是已经足够应付读取场景”很多性能问题能从源头避免。5.5 坑五只建表不更新字典文档变成历史文物现象是线上库加了好几个字段规范里的数据字典整整三个月没动后来没一个人敢依赖文档。原因是字典更新没有和发版流程挂钩更新字典成了可做可不做的小事。解决方法是把“数据字典已同步”作为上线卡点的一部分在发版检查表里加上这个选项。如果做自动化的团队可以在结构 diff 时把字典表也纳入检查发现文档缺失字段就发一条通知给表负责人直到补齐再放行。6. 把规范变成上线前强制卡点一个谁都没法绕过的检查动作要让数据库设计规范活到第二年靠的不是贴标语而是把检查动作卡进发布流程里。我给团队定的最小可行方案是四步第一发版前由表负责人列出本次涉及的结构变更清单第二把新字段、新索引、新枚举和文档里的字段清单做一遍差异差异项必须写明原因第三由 DBA 按第 4.2 节的评审表逐项打勾不允许“先发布后补文档”第四发版后第二天用结构同步工具再对比一次测试库和生产库把差异清点干净。只要把这个循环跑上两个版本文档滞后的概率会明显下降。我还有一个已经养成习惯的做法把“8数据库设计规范.doc”的核心部分提炼成一页速查表贴在工位旁或者开发群公告里。速查表只需要留下表名前缀、主键写法、时间字段类型、公共字段列表、单表索引数量上限这几行内容。建表或者改表时扫一眼比打开文档翻半天省力得多。真正有用的数据库设计规范不是备份在共享盘里的历史文件而是每次建表和评审时都会先看一遍的那页纸。希望这篇笔记能帮你把规范从摆设变成工程护栏。如果团队里已经有积重难返的老库别急着一步到位推倒重来先从新模块按规范执行再把老表的差异分批记录、慢慢对齐这条路稳妥得多。本文还有配套的精品资源点击获取