简介：《8数据库设计规范》是一份针对Oracle数据库设计的中文规范文档，面向系统设计师、DBA和后端开发人员，核心解决数据模型不统一、命名不规范、字段类型选用随意等常见问题。文档将保密级别、变更记录等管理要素纳入其中，并围绕编写目的、数据库策略、命名规范、数据模型产出物四大板块展开：既要求数据模型全局单一、基于统一元数据管理，也明确OLTP与OLAP须分开设计；针对数据完整性建议满足第二范式并尽量满足第三范式，减少外键与触发器依赖，同时为OLAP系统的合理冗余留出空间。字段类型方面，文档给出CHAR、VARCHAR2、NUMBER、DATE、BLOB/CLOB的选用原则，并规定了常用字段长度推荐值，如金额用NUMBER(16,2)、名称用VARCHAR2(50)等；命名规范细分到数据库、表空间、表、字段、视图、序列、存储过程、函数、索引与约束，并建议避免以IS_开头的布尔字段命名。资源压缩包内共有1个doc文件，大小296KB，为完整的Word版规范文档，便于按目录检索并直接嵌入团队开发规范。目前已有267人学习浏览，适合需要快速统一数据库设计标准的中小型开发团队参考。
1. 数据库设计规范文档：一份能直接塞进评审流程的Oracle建模底线
做数据模型评审这几年，我见过太多“能跑就行”的库表设计：字段类型随手写VARCHAR2(255)、主键一律叫ID、生产库名带个DEV后缀没人管，最后OLTP系统被全表扫描拖垮才回头翻规范。这份《8数据库设计规范.doc》是典型的Oracle项目落地文档，不说空话，直接给策略、给命名规则、给字段长度推荐值，还带PDM产出物要求和XML表结构文件的属性说明。适合正要建新库、准备统一建模规范、或者要给现有系统做结构整改的团队，新手能照着定表，熟手能拿来当评审checklist，直接解决“库表命名乱、字段类型随缘、产出物对不上”这三类最常见问题。
2. 数据库策略与字段类型：先把OLTP和OLAP的底仓分清
2.1 对象长度与完整性策略：第二范式打底，第三范式看业务
这份规范在数据库策略上有一个很明确的倾向：约束能不用就不用，完整性尽量交给业务逻辑。原文写得很直接——“数据完整性尽量通过业务逻辑实现，数据库设计应尽量避免使用大量的外键约束，避免使用触发器”。这在Oracle生产环境里是站得住脚的。外键在并发写入时会引入额外的锁和校验开销，触发器则会把业务逻辑埋进数据库，排障时多一层黑匣子。但这不是说外键和触发器禁用，而是“尽量少用”。实际操作上我一般这样把握：核心链路、并发高的表不做外键约束，在应用层校验；配置类、低频写入的表保留外键，为的是防止脏数据。
长度策略上，文档给的是原则——根据业务对象类型、字符集、时间格式定长度，而不是拍脑袋写个255。Oracle的VARCHAR2按字节计算长度，如果库用UTF-8字符集，一个汉字占3字节，VARCHAR2(50)只能存16个汉字。文档推荐长度用偶数，本质是给字符集扩展留余量。
2.2 规范化与性能的权衡：OLTP讲范式，OLAP敢冗余
文档对OLTP和OLAP给了两套标准：OLTP无特殊理由必须遵循第三范式，OLAP为了减少表间连接、提高响应时间，可以保留合理冗余。这是Oracle设计里很实用的一个判断：规范化不是目的，是手段。
第三范式要求字段不传递依赖，也就是一张表里只存与主键直接相关的数据。比如订单表里冗余客户姓名，这在OLTP第三范式眼里是不合格的，因为客户姓名通过客户ID就能关联出来。但到了报表分析场景，每次查询都要去join客户表，性能代价远大于那点冗余。文档的价值在于把这个取舍摆到了台面上——先按规范化设计，性能瓶颈出现时再反规范化，而不是一开始就乱堆字段。
如果按这份规范去做表设计，需要考虑常见的拆分桶思路，把OLTP的表拆到第三范式，把统计指标、汇总数据单独建模成分析表或中间表，避免在业务表上跑重聚合查询。
2.3 字段类型定义与常用字段长度参考
数据类型的选择直接决定存储效率和查询行为。文档要求Oracle必须用NUMBER替代REAL、FLOAT、INTEGER，因为Oracle的NUMBER可以声明精度和标度，能精确控制小数位。时间类型统一用DATE，二进制用BLOB，大文本用CLOB。CHAR和VARCHAR2的分界也很清楚——静态编码、固定长度字段用CHAR，变长数据一律VARCHAR2。
文档给了实用的字段长度推荐表，我把常用部分整理如下，可以直接参考：
| 业务含义 | 推荐类型与长度 |
|---|---|
| 金额、销售额 | NUMBER(16,2) |
| 税率、比例、分成 | NUMBER(10,6) |
| 货物单价 | NUMBER(16,6) |
| 人数、计数 | NUMBER(10) |
| 人名 | VARCHAR2(50) |
| 单位名称、地址 | VARCHAR2(100) |
| 说明、理由、意见 | VARCHAR2(200) |
| 静态编码、固定年月日 | CHAR(1)或CHAR(4)等固定长度 |
| 二进制数据 | BLOB |
| 大文本 | CLOB |
还有一个细节值得注意：文档建议业务表中增加optr_code（操作员工号）、opt_date（操作时间）、remark（备用字段）、stand（备注）四个通用字段。这四件套在大部分业务系统里都适用，我见过的投产系统大多也保留了类似的审计字段，区别只是命名略有调整。optr_code和opt_date是审计需要，remark和stand是给后期业务预留的扩展位，好过一上线就要加列。
2.4 描述“是/否”的字段命名：别用IS_开头
文档里有一条容易被忽略但很重要的命名约定：“描述是、否类型的字段命名，避免使用IS_开头”。这条和JavaBean的布尔属性命名习惯直接冲突，很多人在这上面翻过车。Java里isFlag是合法属性名，但Oracle的保留字列表里正好有IS，如果SQL里写WHERE is_valid = 1，在某些版本的工具或框架下会触发解析异常。规避做法是用flag、status这类词代替。
实际项目里我会把这类字段命名为FLAG_VALID、FLAG_DELETED、STATUS_EFFECTIVE，用FLAG做前缀不只是为了避开保留字，更重要的是在几十张表里一眼能看出这是布尔标记。
3. 命名规范：从库名到约束的完整编码体系
3.1 数据库命名规则：项目简称加类型代码加识别代码
文档给出了一个可执行的库名模板：项目简称 + 1位数据库类型代码 + 识别代码 + 序号。这个规则用来解决两个问题——库的类型识别和运行环境识别。类型代码有三个：T代表业务型、A代表分析型、H代表历史库。识别代码有两个：DEV代表开发库、TEST代表测试库，生产库不加识别代码。
文档给的例子很直观：
- 出入系统业务生产库：AOCT、AOCT1、AOCT2
- 出入系统业务开发库：AOCTDEV、AOCTDEV1、AOCTDEV2
- 出入系统业务测试库：AOCTTEST、AOCTTEST1、AOCTTEST2
这条规则在维护期特别有用。接手一个旧系统时，看到库名就知道它是什么环境、什么用途，不会把一个测试库里调整过的数据当成生产数据去排查。唯一要注意的是序号只在使用同类型多个库时追加，单库不写序号。
3.2 表命名与字段命名：前缀体系和三层后缀规则
表的命名规则分为业务库和分析库两套。业务库是子系统简称_业务含义，比如订单子系统的表可能是ORD_ORDER_INFO。分析库的规则不同，文档明确给了四类前缀：
- ODS_：操作型数据存储区
- FACT_：事实表
- DIM_：维表
- MID_：中间表
字段命名是这份规范里实操价值最高的部分。文档定义了三个强制后缀：
| 后缀 | 适用场景 | 示例 |
|---|---|---|
| _ID | 与业务含义无关的主键或外键标识 | PARTY_ID |
| _CODE | 有业务含义的编码、代码 | PARTY_CODE |
| _NAME | 名称、姓名 | PARTY_NAME |
同时要求主键和外键使用相同的字段名和数据类型，尽量少用联合主键。主键不要用自增类型，而是用“前缀+流水号”的有含义生成规则。这条和第2章说的不用外键约束呼应——主外键字段名保持一致，即使没有外键约束，join时的可读性也有保障。
3.3 视图、序列、存储过程、函数、索引、约束命名规则
视图用VW_子系统简称_业务含义，序列用SEQ_表名，存储过程用PRC_子系统简称_业务含义，函数用FUN_子系统简称_业务含义。这套规则几乎没有歧义，照着拼就行。索引规则是IDX_表名_有关字段，不允许用自动生成的索引。
约束的命名有单独讲究。主键是PK_表名，外键是FK_表名_字段_被参照表名。这里有个隐藏坑：Oracle的约束名有长度限制，如果表名太长，PK_加表名会超限导致创建失败。文档里专门提了“表名部分要尽量简化且易于区分”。我之前在客户现场就遇到过表名接近30个字符、主键约束名超长报ORA-00972的情况，最后只能截断表名再拼约束名。所以表名也不是越长越好，20个字符以内是比较稳妥的区间。
3.4 保留字与一般命名原则
文档最后附了完整的保留字表，不允许用在对象命名上。里面有Oracle的，也有SQL标准和其他数据库的保留字，一个大杂烩列表。实际中建议至少避开Oracle官方保留字，表结构设计完建表前跑一遍关键字校验。命名上还要求以A-Z开头，非前导字符只用A-Z、0-9和下划线，对象名长度不超过18个字符。
这里要注意，保留字的坑在Java实体映射时也会出现。比如字段叫SIZE、COMMENT、LEVEL，在MyBatis或者JPA里映射规则稍有差异，就可能生成出问题的SQL。用这份文档的规范，类似风险可以从源头避免。
4. 数据模型产出物与XML说明：把设计落到可交付的文件
4.1 PDM、XML、建表脚本三类产出物
文档要求数据模型的设计产出物统一为三类：PDM文件、XML文件、建表脚本。PDM文件是PowerDesigner的物理数据模型，XML是通过PDM转换得到，建表脚本则要严格按版本控制管理。
PDM文件是设计源头，概念模型和物理模型可以分开。XML文件用于数据结构列表展示，文档里的附录A专门说明了xml格式。建表脚本分两类：创建类（create_table.sql）和修改类（alter_table.sql），修改脚本只是备忘，所有表结构修改必须实时更新PDM和创建脚本。这一点是Oracle项目里最常见的协同问题——改表结构的同事只更新了alter脚本，没同步PDM，导致三份产物不一致。
4.2 脚本命名与维护要求
文档给定的脚本命名如下：
- 创建表脚本：
项目简称_create_table.sql - 修改表脚本：
项目简称_alter_table.sql - 创建存储过程脚本：
项目简称_create_prc.sql - 创建函数脚本：
项目简称_create_fun.sql - 创建视图脚本：
项目简称_create_view.sql
存储过程、函数、视图的创建和修改都必须实时更新对应文件。实际操作中，我会再加一个readme或版本目录，记录每个脚本最后变更的时间戳和提交人。光靠文件名区分版本是不够的，git或者svn的提交记录才是真正的权威来源，脚本本身保持“当前最新结构”即可——旧的alter语句只做历史留痕。
4.3 XML文件的节点结构与属性含义
XML的部分在正式项目里容易被忽略，但它实际上是连接表结构和代码生成的桥梁。文档给出的XML结构固定带两行头：
<?xml-stylesheet type="text/xsl" href="ui/TL_Schema.xsl"?> <!DOCTYPE app-data SYSTEM "ui/TL_Schema.dtd">这两行用于在浏览器里以列表形式展示表结构，所有表结构文件都必须引用。根节点app-data下是database，database下允许挂多个module，module对应项目模块；module下是submodule，submodule对应子模块；再往下才是table。
table的节点属性信息量大，我直接以注释形式拆解一份可用的示例：
<table name="DEPLOY_MACHINE" chineseDescription="主机信息" pkg="com.tl.deploy.machine" jspPath="com/tenglong/deploy/machine" function1="all"> <rem>这里写表的注释、修改信息</rem> <column name="PID" primaryKey="true" required="true" type="VARCHAR" size="32" chineseDescription="内码" queryShow="true" searchShow="true" updateShow="false" insertShow="true" detailShow="true"/> <column name="MACHINE_NAME" type="VARCHAR" size="50" chineseDescription="机器名称" required="false" searchShow="false"/> </table>这里逐个说明关键属性：
name：表英文名chineseDescription：表中文名pkg：自动生成Java类的包路径jspPath：自动生成JSP的存放路径function1：生成功能标识，all表示生成增删改查全套head、line：分别标识主表、细表- column的
primaryKey：标识主键列 required：是否允许为空type、size：字段类型和长度queryShow：查询列表是否显示searchShow：查询条件是否显示updateShow：修改页面是否显示insertShow：插入页面是否显示detailShow：明细页面是否显示enumValue：允许值及含义，如1:JSP,2:CLASS
这段XML的价值是它将表结构属性直接绑定到了代码生成策略。不需要额外写一套页面设计文档，字段在哪个页面展示、能否编辑、能否作为查询条件，全部由XML驱动。维护时改一个属性，重新走一遍生成流程就能刷新页面能力。文档里还有<foreign-key>和<reference>节点，用来描述跨表引用，local和foreign属性将当前表字段与引用表字段关联起来。
4.4 字段展示属性与代码生成配合
这套XML属性在生成型项目里能省大量重复开发。举个例子，一个表的创建时间和操作员工号，通常不需要在新增页面出现，只需要在列表和详情展示。对应地，insertShow设成false，queryShow和detailShow设成true。这些属性在传统开发模式下要靠前端开发手工控制，有了XML定义后，页面渲染直接取配置，前后端各干各的。
要注意，XML的生成是单向的——从PDM到XML。如果手工改了XML但没回写PDM，下次从PDM重新导出会把手工改动覆盖掉。所以规范里说“PDM文件实时更新”，不是空话，是防覆盖的唯一手段。
5. 落地这套规范时常见的五个坑
5.1 生产库名加了DEV后缀，测试环境连错库
现象：开发环境连的生产库，跑批任务半夜把测试数据写进了正式环境。排查后发现测试环境的数据库连接串和脚本里写的是同一个库，两个环境的库名都是AOCTDEV。
原因：部署脚本从开发环境复制到生产环境时，库名没有同步替换，或者替换时只改了应用配置里的连接串，脚本里的库名没改。按照命名规则，生产库应该是不带DEV和TEST的AOCT，靠库名就能区分环境。
解决：严格执行生产库不加识别代码的规则，同时部署流程里加一步“库名校验”，在所有SQL脚本执行前对比目标库名和当前环境期望值，不一致直接拒绝执行。
5.2 CHAR类型存变长数据，几十个空格把SQL搞慢
现象：业务表里有个字段叫STATUS，定义成CHAR(100)，实际只存Y/N，结果每次查询都要走TRIM，而且索引效果很差。
原因：设计人员误以为CHAR(100)和VARCHAR2(100)差不多，忽略了一个关键差异——CHAR是定长，存“Y”也会补99个空格，Oracle比较时会自动trim，但存储和索引依然按100字节算。文档里那条“本规范不推荐长度不为1的字段使用char类型”就是防这个的。
解决：按规范把状态标记改成CHAR(1)，或者干脆用VARCHAR2(2)存Y/N。存量表如果已经用CHAR(100)，需要评估空间占用和索引成本，必要时做表结构迁移。
5.3 主键约束名超长，建表脚本执行报ORA-00972
现象：表名长到28个字符，按规则生成PK_加表名后约束名超过30字节，Oracle直接报错。开发同事想当然缩短为PK_加前8个字符，结果另一个表也用了同样的前缀，两个主键约束名撞了。
原因：约束命名规则写的是“PK_表名”，但Oracle对象名上限是30字节，中文表名或超长表名很容易超限。文档专门提示了“表名部分要尽量简化且易于区分”，这里恰恰是最容易被忽略的一行字。
解决：表设计阶段控制表名长度，主键约束用PK_业务模块_表名缩写，在不超过30字节的前提下让规则可读。批量生成脚本前，用SQL查一遍USER_CONSTRAINTS确认无重名无超长。
5.4 改了表结构只顺手改alter脚本，PDM和create脚本不同步
现象：项目上线第三周，新同事加了一个字段，只在alter_table.sql里添加了ALTER语句。月底评审时，用create_table.sql在测试库重建表结构，字段缺失，所有下游脚本报错。
原因：文档规定“修改表脚本只作为备忘，所有表结构的修改，都必须实时更新PDM文件，并且更新创建表脚本”，但实际开发中没有硬性流程卡住这一点。alter脚本变成事实上的唯一维护入口，create脚本已经过期。
解决：把create_table.sql当作表结构的唯一权威来源，每次alter脚本提交前，必须同步改动create脚本。用脚本做自动化检查：对比alter脚本里的ADD COLUMN字段和create脚本里的字段集合，不一致则提交失败。
5.5 字段用IS_开头，JDBC和存储过程双双出错
现象：表里有个IS_VALID字段，Java代码用MyBatis查询没问题，但一个PL/SQL存储过程里写WHERE IS_VALID = 1直接报ORA-00936。
原因：字段名以IS开头，虽然Oracle的保留字表里IS是关键字而不是完全禁用，但在某些SQL上下文中解析规则不同，容易触发语法错误。文档明确说了“避免使用IS_开头”，但Java端的is前缀习惯让开发人员无意识踩坑。
解决：命名阶段用统一后缀，不如直接用FLAG_VALID、FLAG_DELETED这类带前缀的写法。PL/SQL里如果必须用，加双引号可以规避，但这不是长期方案——双引号引用的标识符区分大小写，容易引入新的不一致。
6. 把规范落进团队的评审检查清单
拿到这份文档容易，真正难的是让它从“某个同事网盘里的文档”变成“每天写表结构时脑子里过一遍的规则”。我的做法是把规范压缩成一张评审检查表，每次数据模型评审时逐条过：
| 检查项 | 依据 |
|---|---|
| 库名是否含类型代码和识别代码，生产库不带DEV/TEST | 3.1 |
| 业务表是否符合第三范式，分析表是否合理冗余 | 2.3 |
| 主键是否用ID后缀或有含义编码，是否避开自增 | 3.5 |
| 字段名是否以_ID、_CODE、_NAME规范收尾 | 3.5 |
| 是否出现IS_开头的字段名 | 2.4 |
| VARCHAR2长度是否为偶数，是否符合业务含义 | 2.4 |
| 金额、税率、人数等常用字段是否按推荐长度定义 | 2.4 |
| 视图、序列、存储过程、函数命名是否带前缀 | 3.6-3.9 |
| 索引名是否含表名和字段名，是否禁用了自动索引 | 3.10 |
| 主键外键约束名是否超长，是否可读 | 3.11 |
| 表结构修改是否同步了PDM、create脚本、alter脚本 | 4.3 |
| XML中字段的insertShow、updateShow是否与页面需求一致 | 4.4 |
有了这张表，评审就不再是坐在一起看PPT，而是对着库表清单一条条打钩。如果有些表已经投产，整改时不要一次性推倒重来。常见做法是存量表继续用，新表严格按规范执行，版本迭代时逐步把老表的字段名、索引名、约束名对齐过来。索引改名对运行中系统是有风险的，需要评估删除重建窗口。
关于字段类型，我实际使用时会比文档更激进一点：Oracle 12c以上建议用VARCHAR2(4000)做兜底长度，但不要有“既然能存4000就全用4000”的心态，表里超过一半字段都是4000长度时，块利用率会很难看。该按业务定义长度的字段，老老实实按文档给的推荐走。
命名规范这件事，最大的收益不在设计期，在维护期。项目运行三年后，人员换了一拨，新来的同事打开库看到FACT_ORDER_DAILY和DIM_PARTY，不需要翻文档就能判断哪张是事实表、哪张是维表；打开一个字段叫PARTY_CODE的列，不用猜就知道存的是客户编码。这就是规范的全部意义。文档里的每个后缀、每个前缀，都是在给三年后的人留路标。
一个实际的检验方法：把库里的对象名导出来，去掉前缀后缀后如果还能准确猜出这个对象是干什么的，命名就是合格的；如果猜不出来，说明命名规则没有真正生效。我每次接手新库第一件事就是跑这条检验，比看任何设计文档都直观。希望这套规范里的命名体系和落地方法，能帮你在建库之前就把这些坑提前填平。
本文还有配套的精品资源，点击获取
