尧图网页设计 
简介《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 typetext/xsl hrefui/TL_Schema.xsl? !DOCTYPE app-data SYSTEM ui/TL_Schema.dtd这两行用于在浏览器里以列表形式展示表结构所有表结构文件都必须引用。根节点app-data下是databasedatabase下允许挂多个modulemodule对应项目模块module下是submodulesubmodule对应子模块再往下才是table。table的节点属性信息量大我直接以注释形式拆解一份可用的示例table nameDEPLOY_MACHINE chineseDescription主机信息 pkgcom.tl.deploy.machine jspPathcom/tenglong/deploy/machine function1all rem这里写表的注释、修改信息/rem column namePID primaryKeytrue requiredtrue typeVARCHAR size32 chineseDescription内码 queryShowtrue searchShowtrue updateShowfalse insertShowtrue detailShowtrue/ column nameMACHINE_NAME typeVARCHAR size50 chineseDescription机器名称 requiredfalse searchShowfalse/ /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设成falsequeryShow和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/TEST3.1业务表是否符合第三范式分析表是否合理冗余2.3主键是否用ID后缀或有含义编码是否避开自增3.5字段名是否以_ID、_CODE、_NAME规范收尾3.5是否出现IS_开头的字段名2.4VARCHAR2长度是否为偶数是否符合业务含义2.4金额、税率、人数等常用字段是否按推荐长度定义2.4视图、序列、存储过程、函数命名是否带前缀3.6-3.9索引名是否含表名和字段名是否禁用了自动索引3.10主键外键约束名是否超长是否可读3.11表结构修改是否同步了PDM、create脚本、alter脚本4.3XML中字段的insertShow、updateShow是否与页面需求一致4.4有了这张表评审就不再是坐在一起看PPT而是对着库表清单一条条打钩。如果有些表已经投产整改时不要一次性推倒重来。常见做法是存量表继续用新表严格按规范执行版本迭代时逐步把老表的字段名、索引名、约束名对齐过来。索引改名对运行中系统是有风险的需要评估删除重建窗口。关于字段类型我实际使用时会比文档更激进一点Oracle 12c以上建议用VARCHAR2(4000)做兜底长度但不要有“既然能存4000就全用4000”的心态表里超过一半字段都是4000长度时块利用率会很难看。该按业务定义长度的字段老老实实按文档给的推荐走。命名规范这件事最大的收益不在设计期在维护期。项目运行三年后人员换了一拨新来的同事打开库看到FACT_ORDER_DAILY和DIM_PARTY不需要翻文档就能判断哪张是事实表、哪张是维表打开一个字段叫PARTY_CODE的列不用猜就知道存的是客户编码。这就是规范的全部意义。文档里的每个后缀、每个前缀都是在给三年后的人留路标。一个实际的检验方法把库里的对象名导出来去掉前缀后缀后如果还能准确猜出这个对象是干什么的命名就是合格的如果猜不出来说明命名规则没有真正生效。我每次接手新库第一件事就是跑这条检验比看任何设计文档都直观。希望这套规范里的命名体系和落地方法能帮你在建库之前就把这些坑提前填平。本文还有配套的精品资源点击获取 Oracle数据库设计规范：从字段类型到命名规则的落地指南
简介《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 typetext/xsl hrefui/TL_Schema.xsl? !DOCTYPE app-data SYSTEM ui/TL_Schema.dtd这两行用于在浏览器里以列表形式展示表结构所有表结构文件都必须引用。根节点app-data下是databasedatabase下允许挂多个modulemodule对应项目模块module下是submodulesubmodule对应子模块再往下才是table。table的节点属性信息量大我直接以注释形式拆解一份可用的示例table nameDEPLOY_MACHINE chineseDescription主机信息 pkgcom.tl.deploy.machine jspPathcom/tenglong/deploy/machine function1all rem这里写表的注释、修改信息/rem column namePID primaryKeytrue requiredtrue typeVARCHAR size32 chineseDescription内码 queryShowtrue searchShowtrue updateShowfalse insertShowtrue detailShowtrue/ column nameMACHINE_NAME typeVARCHAR size50 chineseDescription机器名称 requiredfalse searchShowfalse/ /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设成falsequeryShow和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/TEST3.1业务表是否符合第三范式分析表是否合理冗余2.3主键是否用ID后缀或有含义编码是否避开自增3.5字段名是否以_ID、_CODE、_NAME规范收尾3.5是否出现IS_开头的字段名2.4VARCHAR2长度是否为偶数是否符合业务含义2.4金额、税率、人数等常用字段是否按推荐长度定义2.4视图、序列、存储过程、函数命名是否带前缀3.6-3.9索引名是否含表名和字段名是否禁用了自动索引3.10主键外键约束名是否超长是否可读3.11表结构修改是否同步了PDM、create脚本、alter脚本4.3XML中字段的insertShow、updateShow是否与页面需求一致4.4有了这张表评审就不再是坐在一起看PPT而是对着库表清单一条条打钩。如果有些表已经投产整改时不要一次性推倒重来。常见做法是存量表继续用新表严格按规范执行版本迭代时逐步把老表的字段名、索引名、约束名对齐过来。索引改名对运行中系统是有风险的需要评估删除重建窗口。关于字段类型我实际使用时会比文档更激进一点Oracle 12c以上建议用VARCHAR2(4000)做兜底长度但不要有“既然能存4000就全用4000”的心态表里超过一半字段都是4000长度时块利用率会很难看。该按业务定义长度的字段老老实实按文档给的推荐走。命名规范这件事最大的收益不在设计期在维护期。项目运行三年后人员换了一拨新来的同事打开库看到FACT_ORDER_DAILY和DIM_PARTY不需要翻文档就能判断哪张是事实表、哪张是维表打开一个字段叫PARTY_CODE的列不用猜就知道存的是客户编码。这就是规范的全部意义。文档里的每个后缀、每个前缀都是在给三年后的人留路标。一个实际的检验方法把库里的对象名导出来去掉前缀后缀后如果还能准确猜出这个对象是干什么的命名就是合格的如果猜不出来说明命名规则没有真正生效。我每次接手新库第一件事就是跑这条检验比看任何设计文档都直观。希望这套规范里的命名体系和落地方法能帮你在建库之前就把这些坑提前填平。本文还有配套的精品资源点击获取