数据库设计规范

6.1 数据表
设计数据库表时，表上的字段数量应该合适。可以从以下几个方面考虑：
1）从数据检索速度来说，字段越少越好，但是太少，很多情况下，势必要使用表连接；
2）字段太多则会影响数据的检索速度，超过50个字段需要分析评审；
3）最低要求是，表中的任意一条记录的数据总和不能大于一个数据块的大小。可使用如下SQL进行检查：select t.table_name,sum(t.data_length) from user_tab_cols t group by t.table_name having sum(t.data_length) > 8192
4）字段建议设置默认值，以便更好的使用索引。
6.2 包
相同模块的多个函数或存储过程可以考虑放到一个包中；
多个存在关联的函数或存储过程可以考虑放到一个包中；
包注释中应注明所属项目组及责任人。
6.3 存储过程
存储过程格式严格按照以下格式编写：
Create or replace procedure 存储过程名 [(输入输出变量列表)]
As
[内部变量列表]
Begin
存储过程内容;
End 存储过程名;
输入参数以“i_开头，输出参数以“o_”开头，输入输出参数用io_开头；
存储过程中引用数据库对象时，不得含有schema信息；
存储过程调用其他存储过程或函数的层级不能超过3级，如果超过3层一定要有对应的设计文档，并在注释中写明配置库存放路径，以避免阅读困难；
存储过程中的DML操作尽量加上事务控制语句commit或者rollback；
存储过程中尽量不要用游标，如果一定要用，尽可能使用显示游标，避免使用隐式游标；
重复调用的业务规则、处理逻辑，应封装到单独的函数或存储过程中，以便于维护；
所有存储过程必须在结束前统一捕获系统异常，并将异常记录到日志表中。
6.4 函数
函数格式严格按照以下格式编写：
Create or replace function 函数名 [(输入变量列表)] return 返回变量类型
As
[内部变量列表]
Begin
函数内容;
End 函数名;
函数中引用数据库对象时，不得含有schema信息；
函数调用其他存储过程或函数的层级不能超过3级，如果超过3层一定要有对应的设计文档，并在注释中写明配置库存放路径，以避免阅读困难；
一般情况下函数中不使用事务，如果要使用必须加上事务控制语句commit或者rollback；
函数中尽量不要用游标，如果一定要用，尽可能使用显示游标，避免使用隐式游标；
重复调用的业务规则、处理逻辑，应封装到单独的函数或存储过程中，以便于维护；
所有函数必须在结束前统一捕获系统异常。
6.5 约束
数据库约束主要是用来维护数据的完整性，在数据的增删改前做检查，这个检查可能会带来一部分性能损耗。可以从以下方面考虑：
1） 每个表必须有主键。
2） 如果对数据完整性要求不是很高，可以不使用外键约束，建议使用代码控制；
6.6 触发器
设计表触发器时要考虑以下两点：
1） 要避免链式触发，那样很容易产生性能灾难；
2） 触发器的个数要适中，关于触发器对性能的影响参见附件《触发器测试说明》。
6.7 定时器
定时器尽量安排在业务闲暇时段执行，操作大数据量的定时器严禁在业务繁忙时段启动。
需要在业务繁忙时段执行的定时器需要满足处理事务量小、执行时间短等特点。
定时器应注明所属项目组及责任人。
开发组提交给技术管理组审核，审核后由配置组专人管理。

6.8 索引
数据库表上的索引可以加快数据检索的速度，但同时会降低数据增删改的性能。所以需要在权衡利弊后建立正确的索引。可以从以下两个方面考虑：
1） 如果增删改频率很高，那么索引个数不宜多；
2） 如果增删改的频率低，而查询的要求多样，可以考虑创建更多合适的索引。
6.9 分区
在设计时，预计到数据量比较大的表，可以考虑使用分区的方法来提高性能。
分区表的分区字段的确立要根据业务情况来判定，只有在业务中频繁使用的字段才可以考虑作为分区字段。比如：时间字段常用来做范围分区表，地市局代码常用来做列表分区表等。
分区需求要进行评审，参与人：DBA、技术管理组、开发组、配置管理组。
6.10 分表
当一个表中的数据使用频繁度存在非常明显的差异时，可以考虑分表，将使用频繁度低的数据转储到其他表中，只保留使用频繁度高的数据。
一张业务表随着业务的增长，数据量会越来越大。设计时，应该考虑到这些数据量的增长，对于大数据量的情况，应考虑分表。可以从以下几个方面考虑：
1） 将适时数据和历史数据分成不同的表；
2） 适时数据参与业务流程，历史数据只做统计分析；
3） 根据数据量以及查询的方便，确定分表的时间粒度。