《PLSQL编写规范v》由会员分享，可在线阅读，更多相关《PLSQL编写规范v（7页珍藏版）》请在金锄头文库上搜索。
1、3. 基本策略3.1 设计策略u 分类拆分数据量大的表。 对于经常使用的表（如某些参数表或代码对照表），由于其使用频率很高，要尽量减少表中的记录数量。例如，银行的户主账表原来设计成一张表，虽然可以方便程序的设计与维护，但经过分析发现，由于数据量太大，会影响数据的迅速定位。如果将户主账表分别设计为活期户主账、定期户主账及对公户主账等，则可以大大提高查询效率。u 分区策略 在拥有数500行以上的表时，采用分区策略。u 索引设计。 对于大的数据库表，合理的索引能够提高整个数据库的操作效率。在索引设计中，索引字段应挑选重复值较少的字段；在对建有复合索引的字段进行检索时，应注意按照复合索引字段建立的顺序
2、进行。例如，如果对一个万多条记录的流水表以日期和流水号为序建立复合索引，由于在该表中日期的重复值接近整个表的记录数，用流水号进行查询所用的时间接近秒；而如果以流水号为索引字段建立索引进行相同的查询，所用时间不到秒。因此在大型数据库设计中，只有进行合理的索引字段选择，才能有效提高整个数据库的操作效率。u 有时候为了提高性能。减少表的关联，恰当的数据冗余是允许的。u 索引对新增，删除，更新的性能影响比较大，对相关的表的索引使用要权衡u 为表和索引建立不同的表空间，禁止在系统表空间中放入非核心oracle系统成分的对象， 确保数据表空间和索引表空间位于不同的磁盘磁盘驱动器上。u 对于经常发生同时查询
3、或频繁查询的表，最好把他放到不同的磁盘空间上4. 逻辑设计规范4.1 范式u 如果没有性能上的原因，应该使用关系数据库理论，达到较高的范式，避免数据冗余。u 如果在数据量上与性能上无特别要求，考虑到实现的方便性可以有适当的数据冗余，但基本上要达到3NF。4.2 表设计u 对于数据量比较大的表，根据表数据的属性进行分区，以得到较好的性能。如果表按某些字段进行增长，则采用按字段值范围进行范围分区；如果表按某个字段的几个关键值进行分布，则采用列表分区；对于静态表，则采用Hash分区或列表分区；在范围分区中，如果数据按某关键字段均衡分布，则采用子分区的复合分区方法。u 每个表均创建类型为Sequenc
4、e的主键字段。u 每个表中需含有如下几个基本字段：一个表的SEQ号，4个创建信息字段，5-8个备用字段，一个删除标记字段，最好还有一个行版本字段字段名类型备注业务SEQ号整数型作为表主键OBLIGATE1字符型备用字段OBLIGATE2OBLIGATE3OBLIGATE4OBLIGATE5CREATE_USER_IDVARCHAR创建用户IDCREATE_DATETIMEDATE创建时间LAST_UPDATE_USER_IDVARCHAR更新用户IDLAST_UPDATE_DATETIMETIMESTAMP更新时间u 不要用Identify字段作为表的主键与其它表关联。4.3 索引设计u 常规
5、OLTP应用，创建B-TREE索引,不创建位图索引。u 不需要为小型数据表（5000）创建索引。u 给单个表创建的索引不超过5个，特别是海量交易类表。u 索引条件查询结果记录，不超总记录的20%。u 不要给固定选项的字段创建独立索引。如只有男，女的性别字段；是，否的状态字段等，不要创建独立索引，位可以建立复合索引。u 对于复合索引，索引字段顺序比较关键，把查询频率比较高的字段排在索引组合的最前面。u 索引放到独立的表空间，该表空间不需要REDO LOG。u 含有外键约束的表的字段，必须有单独索引。如订单明细的表头外键。5. 对象命名规范5.1 一般规范5.1.1 语言u 命名使用英文单词，不使
6、用复数。u 英文单词使用同对象本身意义相对或相近的单词。选择最简单或最通用的单词。不能使用毫不相干的单词来命名。u 当一个单词不能表达对象含义时，用词组组合，如果组合太长时，采用简写或缩写，缩写要基本能表达原单词的意义。u 当出现对象名重名时，是不同类型对象时，加类型前缀或后缀以示区别。u 禁止使用中文或拼音缩写进行命名5.1.2 大小写u 名称一律大写，以方便不同数据库移植，以及避免程序调用问题5.1.3 单词分隔u 命名的各单词之间使用下划线进行分隔。u 命名的各单词之间不允许有空格存在5.1.4 保留字u 命名不允许使用SQL保留字。5.1.5 命名长度u 表名、字段名、视图名长度应限制
7、在29个字符内(含前缀)。5.1.6 字段名称u 同一个字段名在一个数据库中只能代表一个意思。u 不同的表用于相同内容的字段应该采用同样的名称，字段类型定义。5.2 对象命名规范5.2.1 表命名u 必须为表名加入分类。命名：分类名_表友好名（省略前缀：数据库名简写_TBL_分类名）范例：PM_ROLE_FUNCTION（权限管理_角色功能表）PM：权限管理ROLE_FUNCTION：角色功能表（表友好名）5.2.2 固定表分类名u SYS_：系统信息类，如SYS_LOG日志u CFG_：配置类，CFG_COMPANY公司配置u HIS_：历史信息类，如数据量大则可按时间进行分区配置，如：HI
8、S_01_SI_HEAD一月份的补料历史信息u BUS_：业务类，注意策略中的要求，如果表达到100W以上要用分区u MAP_：映射类，MAP_PACK_LIST包装方式映射表5.2.3 字段命名5.2.3.1 字段命名常用字头u 布林(BOOL)类字段用IS打头u 英名、中文名称用EN和CN结尾区分中英文如：NAME_ENu 统一专用类别字段船公司:OWNER堆场:DEPOT5.2.3.2 主键列u 命名：表友好名_SEQ（省略前缀：数据库名简写_TBL_分类名）u 范例：ROLE_FUNCTION_SEQ（表PUB_TBL_PM_ROLE_FUNCTION的主键）5.2.3.3 外键列u
9、命名：相关表主键名（省略前缀：数据库名简写_TBL_分类名）u 范例：表ROLE_FUNCTION中的外键列ROLE_SEQ是表PUB_TBL_PM_ROLE的主键列名5.2.3.4 一般字段u 命名：字段友好名u 范例：COMPANY_NAME_EN（公司英文名称）5.2.4 索引u 命名：IX_表名_构成的字段名；其中IX 、PK、 UK、FK分别表示为索引、主键、唯一、外键u 范例：IX_PUB_PM_USER_TYPE（为表PUB_PM_USER的USER_TYPE字段创建的索引）5.2.5 视图u 命名：数据库名简写_VIEW_表A名_表B名u 范例：5.2.6 存储过程u 命名：数
10、据库名简写_PRC_存取过程特性名5.2.7 序列u 命名：表名_SEQ（省略前缀：数据库名简写_TBL_分类名）u 范例： ROLE_FUNCTION_SEQ（表ROLE_FUNCTION的主键Sequence）5.2.8 公用表空间u 命名：TBS_存储的特性命名。u 范例：5.2.9 专用表空间u 命名：TBS_表名_NN（NN=1,2,3,4）。u 范例：5.2.10 数据文件u 命名：表空间名_NN.DBF（NN=1,2,3,4）。u u 范例：6. 设计工具u 统一使用Sybase Power Designer作为数据库设计工具，在该工具上完成数据库物理模型的设计，并且由该工具产生
11、数据库脚本。u 所有的数据对象的变更以数据库物理模型为基准。7 过程书写规范1. 目的即使你能够掌握关于一门程序设计语言的所有知识，包括它的语法、获取高性能的技巧，以及高级的功能，你写出的程序实际上仍然有可能既难以阅读，又不好维护，调试起来也非常困难，甚至对于你自己，程序的作者亦是如此。你或许思维敏捷、聪明伶俐，然而你开发的应用程序令你的才干与造诣黯然失色。本章讨论代码的“感觉”，即程序设计的审美问题。我相信你曾经有过阅读结构严密、格式良好的代码的愉悦经历。也许你还对那个程序员的风格与成就深表嫉妒，疑惑他哪儿来的时间把这些方面做得如此妥当。开发人员总是能从谨慎而巧妙地设计代码的布局中得到强烈的
12、自豪感和满足感，然而我们很少有人会花时间为代码设计开发出一种一致的风格。当然，编码风格所造成的影响远远超过了让任何个人感到满足的需要。采用一种一致的、可预见的方式建立程序，能使代码更易于调试和维护。如果每个人都采用自己的编码结构、注释方法和命名习惯，那么每个程序多少都存在一些不易让人理解的地方。除非能完全透彻地理解代码，否则其他人不可能运用你的代码（发现问题的根源、分析代码的依赖性等）。在实际编写代码以前，首先我要讲述采用PL/SQL 语言进行有效编码的风格。这是因为两个原因： 为了让人理解这个观点：如果你打算采用一种代码风格改善应用程序的可读性和可维护性，那么必须在项目的一开始就体现该风格。程序设计风格是在语句编写过程中地对某些细节问题的关注，你不可能在项目完成以后再回过头来，修改现存代码的缩排、大小写和文档格式。 对贯穿本书所使用的格式与风格予以解释。我虽然不能保证本书中的每行代码都遵循这一章的指导方针，但我希望你会意识到一种固定的风格既易于阅读，又有助于理解代码的内容。关于有效的编码风格的那些见解，常常源于天生的信仰（类似于程序员对GOTO用法的观念），也就是说，很大程度上是基于一种信念，而不是合理性。我并不指望你赞成这一章中的所有内容（实际上，在许多地方我提出了几种可供选择的办法）。这种全体一致是不切实际的，也是不必要的。其实，我更希望本章能引起你对自己编程风格的思考。
