数据库设计规范

1、数据库设计规范目的为规范数据库管理，统一数据库设计， 特制定本规范。本规范的主要目的是希望规范数据库设计， 尽量提前避免由于数据库设计不 当而产生的麻烦； 同时好的规范， 在执行的时候可以培养出好的习惯， 好的习惯 是软件质量的很好的保证。数据库设计是指对于一个给定的应用环境， 构造最优的数据库模式， 建立数 据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。数据库物理模型设计意为用 PowerDesigner 或者其他工具生成数据表结构 模型以及其它各种数据库对象。 生成各种数据库对象必须按照该规范的规定进行 创建，以便统一开发和维护。工具： PowerDesigner 15.1设

2、计概要：一个系统对应一个 Model，每个Model下分成多个Physical Diagram，每个 Physical Diagram代表每个子系统的设计模型。命名规范Model 以中文名字命名，如：危废综合监管云平台 V0.1其中 V 是 version 的首写大写字母， 0.1 标明该模型是 0.1 版本，若以后做 修改，将由 DBA 进行升级，该版本号将随着项目的进展而变化升级，如：危废 综合监管云平台 V2.5。数据表相关设计要求通用规范使用英文：要用简单明了的英文单词，不要用拼音，特别是拼音缩写。主要 目的很明确，让人容易明白这个对象是做什么用的；一律大写，特别是表名： 有些数据库，

3、 表的命名乃至其他数据对象的命名是 大小写敏感的，为了避免不必要的麻烦， 并且尊重通常的习惯， 最好一律用大写；数据库对象命名规范表的命名表名的前缀：前缀 _表名。为表的名称增加一个或者多个前缀，前缀名不要 太长，可以用缩写，最好用下划线与后面的单词分开；其目的有这样几个： 为 了不与其他项目或者其他系统、子系统的表重名；表示某种从属关系， 比如表明是属于某个子系统、 某个模块或者某个项目等 等。表示这种从属关系的一个主要目的是， 从表名能够大概知道如何去找相关的 人员。比如以子系统为前缀的， 当看到这个表的时候， 就知道有问题可以去找该 子系统的开发和使用人员；表名称 必须用英文大写字母，且

4、具有代表含义的单词（字母）构成； 表名称命名必须遵循以下规则：T_XXX_YYYT_+每个单词（每个字母大写），表名只有以下下两种情况T_ 代表生产系统。第一种情况；如：（单据审批） T_BILL_EXMINE 中。因为表名可能有 1-2 个单词构成，所以XXX表示T_后的第一个的单词，丫丫丫 T_后的第二个的单 词。第二种情况；如：（申请计划） T_PLAN 中, 同上。表的备注内容，必须写清楚。字段名称 命名必须遵循：a）Name 字段汉语名称；b) Code 字段英文名称， 必须取该字段的英文单词，若有多个单词必须 有下滑线相隔。c) 根据自己的情况命名字段名 ,但是必须是有意义且科学的

5、单词， 必须控制 在 1-2 个 之 内 ， 每 个 单 词 的 每 个 字 母 必 须 大 写 。如 ：( 审 批 顺 序 )EXMINE_ORDERd) Table Property属性中必须有字段的注释(Comment)属性详细描述 下面是一些公用的字段命名a)姓名NAMESb)编号NUMBERSc)时间TIMESd)日期DATESe)如果一张表中有一个以上的；如: XXX_TIMES外键名称命名规则，有一下两种情况 第二种情况，是直接关联的(在同一个系统中) ;如:ID_P_PLAN其中 ID 表示该字段为外键； P_PLAN 为关联表的表 名；并用下划线将它们分隔标注 , 类型为 V

6、ARCHAR2(32) 第二种情况，是间接关联的(不在同一个系统中) ； 如： ID_XXX其中的 ID 表示该字段为外键； XXX 为关联的另外一个系统中的表名， (本 系统中联系了人力资源这个系统) , 类型为 VARCHAR2(32)每 张 表 必 须 有 一 个 名 为 ID 的 键 作 为 主 键 ， 类 型 为 VARCHAR2(32) ，这里的 ID 统一为自增；一定要标注每个字段是否为空； 下面是一些难确定的字段的类型和范围要求 数量，个数等为 NUMBER 价格，金额等为 NUMBER(10,6) 备注，意见，内容等为 VARCHAR2(500) 附件等为 BLOB存储过程相

7、关设计要求存储过程必须有以下注释说明：/*DESCRIPTION:（描述此存储过程的功能或创建存储过程的原因）PARAMETER: （存储过程的输入输出参数说明）CREATE_DATE: （存储过程的创建日期 /修改日期）CREATE_AUTHOR: （创建/修改存储过程的作者）*/函数相关设计要求/*DESCRIPTION: （描述此函数的功能或创建函数的原因）PARAMETER: （函数的输入输出参数说明）CREATE_DATE: （函数的创建日期 /修改日期）CREATE_AUTHOR: （创建/修改函数的作者）*/触发器相关设计要求/*DESCRIPTION: （描述此触发器的功能或创

8、建触发器的原因）PARAMETER: （触发器的输入参数说明）CREATE_DATE:（触发器的创建日期/修改日期）CREATE_AUTHOR: （创建/修改触发器的作者）*视图相关设计要求/*DESCRIPTION:（描述此视图的功能或创建视图的原因）PARAMETER: （视图的输入参数说明）CREATE_DATE:（视图的创建日期/修改日期）CREATE_AUTHOR: （创建 /修改视图的作者）*/数据库对象设计原则表的设计主、外键每个表，都必须要有主键。 主键是每行数据的唯一标识， 保证主键不可随意 更新修改，在不知道是否需要主键的时候， 请加上主键， 它会为你的程序以及将 来查找数

9、据中的错误等等，提供一定的帮助；一个表的某列与另一表有关联关系的时候， 如果加得上的话， 请加上外键约 束。外键是很重要的，所以要特别强调：适量建外键。 为了保证外键的一致性， 数据库会增加一些开销， 如果有确凿 的并且是对性能影响到无法满足用户需求的证据， 可以考虑不建外键。 否则，还 是应该建外键；不要以数据操作不方便为理由而不建外键。 是的，加上外键以后， 一些数据 操作变得有些麻烦，但是这正是对数据一致性的保护。 正是因为这种保护很有效， 所以最好不要拒绝它；以缺省的方式建立外键（即用 delete restrict方式），以达到保护数据一致性 的目的；外键在保护数据一致方面非常有效。

10、 如果不建外键， 数据库中容易出现 垃圾数据， 并且无人知晓。 当数据量很大的时候， 查找这些垃圾数据也是相当困 难的。而应用程序在设计时， 往往没有考虑或者也无法照顾到垃圾数据。 因此垃 圾数据很可能造成应用程序工作不正常， 并且表现出来的现象会很奇怪， 让人摸 不着头脑。列的设计字段的宽度要在一定时间内足够用，但也不要过宽，占用过多的存储空间 , 对于长度不确定的列，采用可变长度的数据类型如 varchar 类型；字段的类型及宽度在设计以及后面进行开发时， 往往要与应用的设计、 开发 人员商讨，以得到双方认可的类型及宽度；除非必要，否则尽量不加冗余列。 所谓冗余列， 是指能通过其他列计算出

11、来 的列，或者是与某列表达同一含义的列， 或者是从其他表复制过来的列等等。 冗 余列需要应用程序来维护一致性， 相关列的值改变的时候， 冗余列也需要随之修 改，而这一规则未必所有人都知道， 就有可能因此发生不一致的情况。 如果是应 用的特殊需要， 或者是为了优化某些逻辑很复杂的查询等操作， 可以加冗余列；除非必要，否则尽量不使用LONG, TEXT, BLOB, CLOB, NCLOB, LONG , LONG RAW 这一类的数据类型， 而 是使用其他可以替代的数据类型；优先使用 varchar2类型替代CHAR类型，除 非列宽有严格的要求而且得到应用严格支持；记录数单表的记录数一般控制在两

12、千万条 （参考值，各应用可以根据实际情况进行 适量调整 ） 以内；记录数在两千万和两亿条之间的表一定要采用分区技术， 并根据应用的使用 情况创建合适的分区标准，单个分区内的记录数一般控制在两千万条（参考值，各应用可以根据实际情况进行适量调整 ）以内，同时表的索引使用对应的分区索 引；记录数超过两亿条的表一定要考虑信息生命周期，必须考虑历史数据的剥 离，并在应用设计中完成对历史数据的相应处理功能 （历史数据的剥离规则须经 业务使用部门的确认） ；索引的设计索引是从数据库中获取数据的最高效方式之一。 95%的数据库性能问题都可 以采用索引技术得到解决。但大量的 DML 操作会增加系统对索引的维护成

13、本， 对性能会有一定影响， 对于插入相当频繁的表要慎重建索引， 索引也会占相当的 存储空间，所以要根据硬件环境和应用需求在空间和时间上达到最好的平衡点， 主要原则：适当利用索引提高查询速度：当数据量比较大，了解应用程序的会有哪些 查询，依据这些查询需求建相应的索引； 最好亲自试验一下， 模拟一下生产环境 的数据量， 在此数据量下， 比较一下建索引前后的查询速度； 索引对性能会有一 定影响，对于 DML 频繁列的索引要定期维护（重建） 。但是，索引的结构对于 索引的更新 （比如在插入数据的时候） 是有一定优化的， 所以不要在没有试验以 前过分夸大它对性能的影响。最终还是以试验为准；要建实际用不上

14、的索引， 与上条相关， 如果建的索引并不提高任何一应用中 的查询速度，则要把它删除； 有些数据库有相关工具可以发现实际未被使用的索 引，可以利用一下；索引类型的选择： 要根据数据分布及应用来决定如何建立索引， 一般的高基 数数据列（高基数数据列是指该列有很多不同的值）时 ,建立 BTree 索引（一般 数据库索引的缺省类型） ；当低基数数据列（该列有大量相同的值）时，可以考 虑建立位图索引（如果所选数据库支持的话） ，但位图索引是压缩类型索引，所 以 DML （增、删、改）的代价更高，要综合考虑；索引列的选择：如果检索条件有可能包含多列， 创建联合主键或者联合索引， 把最常用于检索条件的列放在

15、最前端， 其他的列排在后面； 不要索引使用频繁的 小型表，假如这些小表有频繁的 DML 就更不要建立索引，维护索引的代价远远 高于扫描表的代价；主键索引在建立的时候一定要明确的指定名称， 不能让系统默认建立主键索 引（可能有些数据库无法指定主键名，则例外） ；外键必须需建索引。 当有一定数据量， 并且经常以外键所在列为关联， 进行 关联查询时，需要建索引（可能有些数据库自动为外键建索引，则例外） ；当有联合主键或者联合索引时，注意不要建重复的索引。举例说明：表 EMPLOYEES ，它的主键是建立在列 DEPARTID 和 EMPLOYEEID 上的 联合主键，并且创建主键的语句中 DEPAR

16、TID 在前， EMPLOYEEID 在后。在这 样一个表里，通常就没有必要再为 DEPARTID 建一个索引了；联合索引的情况 也一样；更 复 杂 的 情 况 ， 比 如 表 EMPLOYEES ， 有 一 个 索 引 建 立 在 列 CORPID, DEPARTID, EMPLOYEEID 三列上，在创建语句中也依据上述顺序， 就 没有必要再为 CORPID 建立索引；也没有必要再建立以 CORPID 在前， DEPARTID 在 后 的 联 合 索 引 ； 如 果 EMPLOYEEID 需 要 索 引 ， 那 么 为 EMPLOYEEID 建立一个索引是不与上面的索引重复的； DEPAR

17、TID 列也类似； 控制一个表的索引数量，尽量使得一个表的索引数量小于五个；视图的设计在不太清楚视图用法的情况下， 尽量不建。 因为一旦建了， 就有被滥用的危 险；如果需要建视图， 只要是打算长期使用的， 请写入数据库设计中。 明确它的 用途、目的；建立视图时要明确写出所有要选择出的列名而不要以 SELECT * 来代替，可 以使结构清晰可读性增强， 也不会增加它对表的所有字段的依赖， 而表是很可能 修改的，特别是增加字段。就很有可能导致使用该视图的应用程序出错； 存储过程、函数、触发器的设计触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干 扰。假如你确实需要采用触发器， 一定

18、要经过测试再应用在生产系统中， 而且必 须集中对它文档化。请把程序包、存储过程、函数、触发器，与应用程序一同加入 CVS 中，进 行版本控制。 因为此四者包含了代码， 应用程序对他们的依赖程度比对表、 视图 的依赖程度更高；适量但尽量少使用存储过程、函数、触发器。使用存储过程、函数、触发器 的影响：(1) 可以减少数据库与客户端的交互，提高性能；(2) 有的数据库还对他们进行了某种程度的编译，在执行的时候，不用再对 其中的 SQL 等语句进行解析，从而提高速度；(3) 如果有多个应用，使用了不同的开发语言，当有某些关键的或者复杂逻 辑希望共享， 则可以考虑使用存储过程或者函数。 因为存储过程等在数据库一级 是共享