您的当前位置：首页合同管理系统技术方案

合同管理系统技术方案

来源：尚车旅游网

合同管理系统技术方案

技术方案

版本 <1.0>

文档信息及版本历史

文档信息项目名称项目编号文档名称储备位置版本

作者/修改者日期描述合同治理系统合同治理系统_技术方案.doc 版权信息

【名目】

概述........................................................................................................................................... 5 1.1 编写目的 ....................................................................................................................... 5 1.2 适用范畴 ....................................................................................................................... 5 1.3 读者对象 ....................................................................................................................... 5 1.4 术语和缩写 ................................................................................................................... 5 1.5 参考资料 ....................................................................................................................... 5 设计概述 ................................................................................................................................... 6 2.1 设计约束 ....................................................................................................................... 6 2.2 设计策略 ....................................................................................................................... 6 2.3 技术实现 ....................................................................................................................... 7

2.3.1 J2EE开发框架 .................................................................................................. 7 系统概述 ................................................................................................................................... 8 1.1 用户现状 ....................................................................................................................... 8 1.2 业务需求分析 ............................................................................................................. 10 系统总体结构 ......................................................................................................................... 11 4.1 功能模块图 ................................................................................................................. 11 4.2 系统架构图 ................................................................................................................. 11 功能描述 ................................................................................................................................. 12 1.1 合同治理 ..................................................................................................................... 12

1.1.1 我的合同 ......................................................................................................... 12 1.1.2 合同起草 ......................................................................................................... 12 1.1.3 合同签署及用印 ............................................................................................. 18 1.1.4 合同履行 ......................................................................................................... 18 1.1.5 合同归档 ......................................................................................................... 18 1.2 合同提醒 ..................................................................................................................... 19 1.3 项目治理 ..................................................................................................................... 20

1.3.1 项目差不多信息治理 ..................................................................................... 20 1.3.2 项目附件治理 ................................................................................................. 21 1.4 产品治理 ..................................................................................................................... 22

1.4.1 产品治理 ......................................................................................................... 22 1.5 合同转移 ..................................................................................................................... 22

1.5.1 转移申请 ......................................................................................................... 22 1.5.2 转移复核 ......................................................................................................... 23 1.5.3 转出记录 ......................................................................................................... 23 1.5.4 转入记录 ......................................................................................................... 23 1.6 范本治理 ..................................................................................................................... 23

1.6.1 范本类型治理 ................................................................................................. 23 1.6.2 范本模版治理 ................................................................................................. 23 1.7 合同台账 ..................................................................................................................... 24 1.8 相对方治理 ................................................................................................................. 26 1.9 档案治理 ..................................................................................................................... 27

6 7

1.9.1 待复核 ............................................................................................................. 27 1.9.2 合同档案 ......................................................................................................... 27 1.10 制度及公告 ............................................................................................................. 28

1.10.1 规章制度及公告公布 .................................................................................... 28 接口设计 ................................................................................................................................. 29 运行环境 ................................................................................................................................. 29 7.1 软件平台 ..................................................................................................................... 29 7.2 硬件清单 ..................................................................................................................... 29 7.3 软件清单 ..................................................................................................................... 30 7.4 数据容量估算 ............................................................................................................. 30 7.5 网络带宽估算 ............................................................................................................. 31 编码规范 ................................................................................................................................. 31 8.1 代码组织与风格 ......................................................................................................... 31

8.1.1 源代码文件约束 ............................................................................................. 31 8.1.2 源代码名目 ..................................................................................................... 31 8.1.3 源代码包结构组织 ......................................................................................... 32 8.1.4 类结构 ............................................................................................................. 32 8.1.5 命名 ................................................................................................................. 36 8.2 代码优化 ..................................................................................................................... 38

8.2.1 代码优化原那么 ............................................................................................. 38 8.2.2 代码优化实践 ................................................................................................. 38 8.3 SQL优化 ...................................................................................................................... 42

8.3.1 提高查询效率原那么 ..................................................................................... 42 8.3.2 SQL语句优化本卷须知 .................................................................................. 45 8.3.3 SQL语句查询案例 .......................................................................................... 46 系统备份设计 ........................................................................................... 错误!未定义书签。

1 概述

1.1 编写目的

本文档为合同治理系统的概要设计文档，概要描述此项目的整体轮廓和各个模块的差不多功能，使得用户对系统有一个整体的了解和差不多认识，应作为设计人员，开发人员，测试人员和爱护人员以的参考依据，并能给用户提供使用说明。

1.2 适用范畴

本文档适用于项目生命周期的各个时期，为设计人员、开发人员、和测试人员能提供开发和测试的参考依据，爱护人员对项目进行了修改后，应该相应的修改本文档。

1.3 读者对象

参与项目的客户，设计人员、开发人员、测试人员、以及爱护人员等等差不多上本文档的读者对象；此文档定义了系统的差不多功能，以及系统架构，系统流程等等。

1.4 术语和缩写

术语和缩写说明备注 1.5 参考资料

参考文件备注 «合同治理系统_需求规格说明书»

2 设计概述

2.1 设计约束

本项目为标准Web应用，能在各种服务器中运行〔比如WebSphere、Tomcat等等〕 2)

连接数据库采纳数据库连接池的方式，建议用JNDI，连接数据库为Oracle 11g版本〔理论上支持各种主流数据库〕 3)

禁止本地IO操作，假如有IO操作，比如上传文件上传到远程FTP服务器上；本应用最后运行在集群和门户上，要求能适应集群和门户环境的要求。 4)

本应用要求要有较高的稳固性，要求能够全天候运行；本应用要有较高的安全性，没有通过认证的用户无法访问本系统。 5)

本应用权限配置要灵活，没有权限的用户无法访问系统内没有授权的模块，同时左边的菜单能依照权限的不同而发生变化；本应用要求连接用数据库连接池，最好使用WAS的数据源； 6)

本系统面向企业的所有职员开发，因此，要求易用性强，人机交互界面友好。 7)

本应用要求有较高的效率，要求绝大多数响应速度在500ms以内。

2.2 设计策略

系统权限要做到灵活，最好能够配置化，能方便的加入治理人员并授予角色，角色与菜单/模块的访问权〔权限〕能无缝连接起来，比如菜单能依照用户的权限的不同而不同。

要求所有的持久层能够业务逻辑层能够复用，各个层次指职责分清晰，严格幸免层次结构不清的现象，比如在Action或者View对数据库操作。

2.3 技术实现

2.3.1 J2EE开发框架

本建设方案将采纳J2EE框架来进行开发完成。

J2EE是一种利用Java 2平台来简化诸多与多级企业解决方案的开发、部署和治理相关的复杂问题的体系结构。J2EE技术的基础确实是核心Java平台或Java 2平台的标准版，J2EE不仅巩固了标准版中的许多优点，例如〝编写一次、到处运行〞的特性、方便存取数据库的JDBC API、CORBA技术以及能够在Internet应用中爱护数据的安全模式等等，同时还提供了对 EJB〔Enterprise JavaBeans〕、Java Servlets API、JSP〔Java Server Pages〕以及XML技术的全面支持。

J2EE提供了一整套核心企业应用程序编程界面，而所有这些界面均为标准的模块化组件。J2EE技术还为这些组件提供一整套企业服务，通过自动化的方式完成应用程序开发中的诸多耗时且费劲的艰巨工作，为用户提供一种可创建广泛兼容的企业解决方案而无需进行复杂编程的平台。利用这一优势能够方便地开发出高质量的、适合企业使用的应用程序，还可极大地减少产品研发上市时刻、成本和风险。

J2EE使用了EJB Server作为商业组件的部署环境，在EJB Server中提供了分布式运算环境中组件需要的所有服务，例如组件生命周期的治理、数据库连接的治理、分布式事务的支持、组件的命名服务等等。有些企业级的EJB Server，例如Sybase公司的EAS 3.6〔Enterprise Application Server 3.6〕还提供了支持高可用性和高性能的群集技术、失败的自动转移和复原、应用负载的自动均衡能力等。实现商业逻辑的EJB组件能够更加高效地运行在应用服务器中，支持多种客户端的访问，的客户端能够先向运行在Web Server上的Java Servlet或者JSP发出要求，在JSP中嵌入Java的代码调用运行在EJB Server中的EJB，以实现商业逻辑；而其他的客户端，能够通过IIOP直截了当访问运行在EJB Server中的组件。

J2EE体系结构的优点是:

1.Java Servlet和JSP都要编译为Java Class才作为Servlet运行，因此

执行性能会明显提高。

2.Java Servlet和JSP中能够完全使用Java进行编程，能够完成许多简单的商业逻辑，专门是JSP，能够直截了当书写HTML，因此简化了页面的输出，如此就保留了脚本语言易于使用的优点。

3.复杂的商业逻辑以组件的形式部署在EJB Server中。由于EJB Server提供了多种组件事务服务，使系统更能够应对大量的并发用户和治理复杂的事务逻辑。

4.EJB Server中集成的组件命名服务能够使组件位置透亮化，简化了组件的部署和客户端应用的爱护。

5.开发过程易于分工，能够由专人负责编写组件，其他人组装页面。 6.J2EE平台全面支持和实施XML，这种强大的组合可使XML具备跨平台的兼容性，甚至用于对XML代码进行语法检查和调试的工具也可与平台无关。J2EE技术和XML技术分别是企业开发的阴阳两极，因为XML可实施独立于平台的数据，而J2EE平台那么可实施独立于平台的解决方案。XML可通过移植的方式表现数据，因此就对Java技术的可移植性构成了补充。

3 系统概述

1.1 用户现状

目前，由于合同缺乏统一的存放治理平台，要查找某合同、补充协议或函件，可能需要到KM系统、档案治理系统、M盘、AI系统、电子邮件、业务经理个人电脑或者信件等纸质文件中查找，专门不方便。依照对公司合同治理的现状分析，要紧问题如下：

 合同治理制度待完善

合同定义：制度已对合同进行定义，但未能有效传达各部门，明白得偏差导致合同归档的完整性得不到保证。

合同分类：未建立合同分类标准。

合同要素：合同关键信息要素模板分散化，各部门治理的程度以及需求不统一，部门间未形成要素信息共享。

合同范本：未明确合同范本的治理流程。

合同对手方库：未建立合同对手方库及相关治理规那么。

合同治理细那么：合同全生命周期相关治理细那么有待更新完善，例如，制度中缺乏爱护合同有效期的相关规定。

 合同治理组织架构待完善

组织架构：目前公司未明确合同治理职能的承担部门，整个合同治理较为松散，未建立监督及问责机制。

岗位职责：目前尚未明确前后台部门之间关于合同的传递、归档、要素化的职责分工与信息共享机制，此外，各部门业务助理兼任合同治理员，但尚未细化和明确其岗位职责。

 补充协议及函件的传递归档待规范

关于部分合同后续履行时期可能显现的补充协议及函件，存在传递不及时、未进行归档的情形，阻碍合同传递的时效性和归档的完整性。

 无法把握公司合同数量及治理状况

合同归档：由于缺乏统一平台，各部门合同治理水平不一，合同存放分散，合同查找和检索的效率低下，不能随时把握公司合同治理情形。

合同有效期：现有系统都不具备合同到期提醒功能，同时由于无法猎取完整的合同清单，现时期依靠手工治理也专门困难。

 合同号的配发缺乏系统操纵

目前合同号的生成依靠档案治理系统手工录入，系统无法自动配发，且合同号可删除，缺乏统一治理。

 当前系统合同治理功能不足

KM系统：承担合同审批及用印申请〔部分另类合同除外〕的职能，缺点是合同版本为过程版本，并非最终盖章生效版本，且合同审批混杂在其他事项审批中，不便于查找。

档案治理系统：承担猎取合同号、保管合同最终用印版本的职能，缺点是合同号配发缺乏系统操纵，由于合同定义不清晰使得合同归档完整性得不到保证，合同要素信息填写不完全，主从合同之间的关联关系依靠手工爱护缺乏专门的系统功能。

M盘：承担部门内共享及临时存放的职能，缺点是没有操作记录，误删除等情形不易被发觉，且存放纷乱缺乏爱护。

AI系统：目前另类投资项目从审批到投后治理已全流程纳入AI系统，但AI系统文档治理功能较弱，仅起到归档保管作用，缺乏合同要素模板和有效期治理等功能。

AD域：AD域的用户治理未做统一用户信息的治理和验证。

1.2 业务需求分析

依照用户现状的梳理，以及相关业务系统的调研分析，整理出合同系统的相关业务需求。

 合同治理系统需要明确合同的定义，以及归档范畴，履行合同的相关制度，明确合同的差不多要素，并对差不多要素进行补充和整理。

 实现对对手库的相关信息进行整理和爱护，建立完善的合同治理对手库信查询功能。

 实现对合同范本的治理和使用，建立完善的合同范本库。

 完善合同的审批和流转操作，建立强大和独立的流程引擎平台，对合同以及相关第三方系统提供流程审批支持，并对合同的状态和合同的到期时刻进行自能化的提醒。

 建立标准化的平台数据对接规范，实现合同系统与各业务系统的数据对接和交换。

建立主从合同的关联关系，并提供方便的查询功能。

4 系统总体结构

4.1 功能模块图

4.2 系统架构图

5 功能描述

1.1 合同治理

合同治理下包含所有当前登录用户经办或代办的全部合同信息。合同治理包括我的合同、合同起草、合同签署及用印、合同履行、合同归档几大部分。

1.1.1 我的合同

我的合同包含合同治理下所有当前登录用户经办或代办的全部合同信息。

1.1.2 合同起草

状态描述：经办人〔代办人〕进行储存但未公布形成的列表。

➢ 功能描述名称、标识符新增合同差不多信息功能描述 1〕、合同号猎取超过7天未进行公布的，系统给经办人〔代办人〕发送提醒信息。 2〕、合同公布后会显示在〝合同签署及用印〞列表下，公布后的合同信息不能再进行删除操作。 3〕、用印形式为〝不用印〞的，填写完签署日期和生效日期后，部门档案治理员能够进行归档申请。 4〕、合同起草能够批量生成100〔手动填写份数〕份以下的相同合同内容，合同号手动进行猎取。 5〕、公司合同治理员能够导出全部合同信息列表excel到本地〔合同起草列表〕，字段：经办人、经办部门合同名称、合同号。 6)、合同到期日期、合同费率〔费率类型、费率种类、费率值〕系统记录每次经办人〔代办人〕修改前后的记录。 7)、经办人〔代办人〕选择到对应的主合同后〔能够选择全部的合同列表〕将主合同的相关信息带入到当前合同中。带入的字段为〔其它主合同信息不显示〕：合同名称、合同分类、合同主体、合同对方 8〕、经办人〔代办人〕所填写的合同一旦在起草中公布，当前合同的状态更新为〝签署中〞；签署日期填写完成后再公布合同状态更新为〝已签署，未生效〞；生效日期填写完成后再公布合同状态更新为〝已生效〞。补充说明 ➢ 数据项描述数据项名称数据类型是否必填数据来源备注说明合同起草页签经办人〔代办人〕填写登记日期日期必填系统自动生成当前日期是否代办字符必填是/否有代办人角色可见；具体见下文说明1；代办人字符系统运算有代办人角色可见；具体见下文说明1；经办人字符必填系统默认当前具体见下文说明1 登录人，可选择经办部门字符必填系统运算具体见下文说明1 主合同编号字符选择/手动填写弹出搜索页面关联查询自动带出主合同要素的相关信息主合同名称字符选择/手动填写弹出搜索页面关联查询自动带出主合同要素的相关信息合同名称字符必填手动填写标识提醒：请填写合同名称全称合同编号字符必填系统按一定规点击按钮猎取，校验那么自动生成前几项是否填写；具体见下文说明2；合同一级分类字符必填下拉框选择具体见下文说明3 合同二级分类字符必填下拉框选择具体见下文说明4 是否客户指定字符必填是/否关心中进行内容说业务明，便于选择是否；选择〝是〞，页面提醒经办人将客户指定投资指令作为合同附件上传；默认为空；项目简称字符下拉框选择弹出搜索页面关联查询；具体见下文说明5；字符多项选择弹出搜索页面关联查询；产品简称具体见下文说明6；〔多个产品币种金额〔大写〕金额〔小写〕删除需填写〕币种金额〔大写〕金额〔小写〕删除币种金额〔大写〕金额〔小写〕删除合同币种字符必填下拉框选择币种为无，金额不填写；具体见下文7；合同金额〔大字符必填依照小写金额可选无写〕转换合同金额〔小数值必填手动填写可选无、其他，能够写〕手动填写内容；具体见下文8；合同费率字符必填费率类型下拉可选无；〔费率类型、框选择；具体见下文9；费率种类〕费率种类对应固定和浮动两种方式；合同费率字符必填可填写具体数〔费率值〕值；合同主体字符必填下拉框选择具体见下文10 合同对方字符必填选择自动补全；标识提醒：请填写合同对方全称；具体见下文11；用印形式字符必填下拉框选择各方用印；仅我方用印；仅对方用印；不用印；具体见下文12；合同签署页签用印治理员、经办人〔代办人〕填写用印完成情形字符必填下拉框选择已完成；我司已完成，对方未完成；〔各方用印〕；具体见下文13；经办人〔代办人〕填写签署日期日期控件选择具体见下文14 合同状态字符必填下拉框选择中止签署；签署中；已签署未生效；合同生效日期合同到期日期到期续签情形日期日期字符必填合同文本合同附件必填备注公布范畴已生效；已失效；控件选择具体见下文15；控件选择下拉框选择到期无异议续签；自动顺延；其它；具体见下文16；手动上传上传一个附件；具体见下文17；合同附件类型能够上传多个附件，选择；记录上传日期；合同附件手动具体见下文18；上传；手动填写手动选择可查看该合同信息转移说明转移附件字符手动填写手动上传附件的人员，具体角色待定。转移申请时可见转移申请时可见说明：1、当前登录人有代办人的角色，能够选择〝是否代办〞，默认为〝否〞，

即当前登录人自己起草合同，系统自动运算当前登录人为〝经办人〞，当前登录人所在部门为〝经办部门〞；

〝是否代办〞选择为〝是〞，即代办人替经办人起草合同，选择〝经办

人〞，系统自动运算经办人所在部门；

如不具有代办人角色，〝是否代办〞、〝代办人〞字段不可见。 2、〝合同编号〞，通过点击按钮按照一定的规那么猎取，猎取合同编号

前校验表单中〝登记日期〞、〝经办人〞、〝经办部门〞、〝合同名称〞是否差不多完成填写，如未填写完成给与提示，否那么生成合同编号。 3、〝合同一级分类〞为可爱护字段，从系统治理数据字典中猎取。 4、〝合同二级分类〞为可爱护字段，选择〝合同一级分类〞后自动选择

对应的〝合同二级分类〞内容，从系统治理数据字段中猎取。

5、〝项目简称〞为可爱护字段，选择项目简称会弹出新的搜索页面，页

面内容为项目简称、项目全称、项目类型〔其他字段不可见〕，能够进行查询选择需要的项目简称。

6、〝产品简称〞为可爱护字段，选择产品简称会弹出新的搜索页面，页

面内容为全部的产品信息，能够进行查询选择需要的产品简称。〔1〕、一个合同编号下能够选择多个产品，选中多个产品后能够填写对

应的多行〝币种〞、〝金额〞信息，默认值为〝无〞经办人可手动修改；

〔2〕、选中一个产品后填写〝合同币种〞、〝合同金额〞、〝合同费率〞

的对应信息；

7、〝合同币种〞为可爱护字段，可选择具体币种和无；

合同币种选择〝无〞，对应的〝合同金额〔大写〕〞、〝合同金额〔小写〕〞字段内容为〝无〞；

8、填写〝合同金额〔小写〕〞后自动运算〝合同金额〔大写〕〞，能够

选择〝无〞或〝其他〞选择项，选择其他能够填写具体内容。

9、〝合同费率〞为可爱护字段，可选具体费率和无。 10、〝合同主体〞内容为选择项，也可填写具体内容。

11、〝合同对方〞为可爱护字段，新增合同公布完成会将合同对方的内容

自动生成一条记录，下次再次新建合同能够选择到之前生成的记录；

合同对方的内容能够进行自动补全；

12、〝用印形式〞内容为选择，分为各方用印、仅我方用印、仅对方用印、

不用印几个选项，具体分以下几种情形：合同主体本企业用印形式各方用印说明办公室治理员完成用印并在系统选择〝用印完成情形〞本企业仅我方用印办公室治理员完成用印并在系统选择〝用印完成情形〞非本企业各方用印线下完成用印后，由经办人填写〝用印完成情形〞、〝签署日期〞、〝合同生效日期〞、〝合同到期日期〞本企业其它仅对方用印线下完成用印后，由经办人填写〝用印完成情形〞、〝签署日期〞、〝合同生效日期〞、〝合同到期日期〞非本企业仅我方用印线下完成用印后，由经办人填写〝用印完成情形〞、〝签署日期〞、〝合同生效日期〞、〝合同到期日期〞本企业其它 13、〝用印完成情形〞内容为选择，分为〝我司已完成，对方未完成〞、

〝已完成〞两个选项；

14、〝签署日期〞

用印完成情形为〝已完成〞公布时需填写签署日期，否那么系统给与提示不承诺公布；

用印完成情形为〝我司已完成，对方未完成〞的公布时该字段能够为空；

15、〝合同生效日期〞

用印形式为〝不用印〞公布时需填写生效日期，否那么系统给与提示不承诺公布；

合同状态选择〝已生效〞，经办人〔代办人〕需填写合同生效日期，

否那么不承诺公布。

16、〝到期续签情形〞为下拉选择框，到期无异议续签、自动顺延、其它

三个选项。合同到期前30天，系统给予提示提醒一次。如为自动续签那么需要填写需要续签的时刻〔XX年〕、合同到期日期两个字段，如选其它能够填写具体内容。

17、〝合同文本〞上传唯独一个附件〔能够上传打包文件〕，未上传附件

公布时系统给与提示。

18、〝合同附件〞能够上传多个附件，能够选择上传附件的类别，附件类

别在系统治理中由治理员进行爱护。 19、表单中增加〝关心〞的链接，用于对合同要素各字段使用说明。

不用印不显示〝用印完成情形〞 1.1.3 合同签署及用印

包含以下几种状态：中止签署、签署中

各个状态在系统中通过不同页签进行分类治理。

1.1.4 合同履行

包含以下几种状态：

已生效、已失效、已签署未生效

各个状态在系统中通过不同页签进行分类治理，默认页签为已生效状态列表。

公司档案治理员确认归档后，经办人〔代办人〕在合同履行时期能够修改非归档字段信息。具体字段如下：合同一级分类合同二级分类项目简称产品简称合同状态合同生效日期合同到期日期到期续签情形合同附件是否客户指定业务 1.1.5 合同归档

状态描述：经办人〔代办人〕填写完成〝签署日期〞后形成的部门档案治

理员待归档和已归档的列表。

经办人〔代办人〕填写完〝签署日期〞点击【公布】后，部门档案治理员能够在〝归档〞列表下查看此条记录，确认系统记录与合同文本内容无误后点击【归档申请】，由公司档案治理员进行归档复核确认。

部门档案治理员能够进行批量申请归档的操作。

具体归档字段如下：

部门治理员归档后带入档案治理的字段经办人经办部门合同名称合同编号主合同编号主合同名称合同币种合同金额〔小写〕合同主体合同对方合同文本合同签署日期 1.2 合同提醒

1.2.1 系统提醒

显示当前用户预先设置过时刻节点且立即或差不多到期的文件，要紧

是提醒用户及时处理相应的事宜。提醒列表样式显示

提醒类型及标题样式〔括号中内容为红色字体〕：

【合同到期】〔还有30天〕+合同名称〔合同编号〕

【进度反馈】〔合同号猎取超过7天未公布〕+合同名称〔合同编号〕

【进度反馈】〔我司已完成用印，对方超过XX天未用印〕+合同名称〔合同编号〕提醒条件：

1、合同到期日期前30天，系统提醒经办人〔代办人〕一次。

2、合同号猎取超过7天未进行公布的，系统提醒经办人〔代办人〕、部门和公司合同治理员一次。

3、合同用印状态为〝我司已完成，对方未完成〞，30天后合同状态为〝签署中〞的系统提醒经办人〔代办人〕，每30天提醒一次。

1.2.2 我的提醒

当前用户能够预先定制自己的提醒信息，以便及时处理相关合同事项。选择对应的合同，设置提醒日期、提醒内容、提醒人员〔默认提醒自己〕。 ➢ 功能描述名称、标识符新建合同提醒信息功能描述补充说明 ➢ 数据项描述数据项名称数据类型是否必填数据来源登记日期日期默认当前日期合同名称字符选择提醒日期提醒人提醒内容

日期字符字符选择提醒日期选择提醒人员手动填写备注说明能够选择到当前用户经办或代办的合同信息列表不选择默认提醒自己； 1.3 项目治理

1.3.1 项目差不多信息治理

要紧对项目差不多信息进行爱护，被设定为项目治理员的人能够进行项目

差不多信息的创建与爱护。

项目文件及项目文件类型创建时默认为空，项目附件创建后能够通过项目简称进行关联。

治理员能够导出全部的项目信息到本地EXCEL，导出列表包含项目简称、项目全称、项目附件类型、项目附件名称。

➢ 功能描述名称、标识符新增项目差不多信息功能描述补充说明 ➢ 数据项描述数据项名称数据类型是否必填数据来源项目编号字符按照规那么自动生成项目全称字符必填手动填写项目简称字符必填手动填写备注说明立项时刻项目类型日期字符项目运作方式字符必填登记人登记日期项目文件字符日期通过全称进行自动复制，并能够进行i需改手动选择手动选择可爱护字段；〔考虑按照AI的项目类型〕下拉选择可爱护字段暂定：自主发行；主导发行；外购；系统自动记录当前登录人系统自动记录当前日期项目附件创建后与对应简称的项目进行关联 1.3.2 项目附件治理

要紧对项目附件进行爱护。

➢ 功能描述名称、标识符新增项目附件功能描述补充说明 ➢ 数据项描述数据项名称数据类型项目简称字符项目文件是否必填数据来源必填下拉选择文件以附件形式上传；项目文件类型下拉选择，为可爱护字段；备注说明，可爱护字段；要件类；权证类；治理类；综合类； 1.4 产品治理

1.4.1 产品治理

要紧对产品简称进行爱护，有权限的人能够进行产品简称的治理。

➢ 功能描述名称、标识符新增产品名称功能描述补充说明 ➢ 数据项描述数据项名称数据类型是否必填数据来源产品编号字符按照规那么自动生成产品全称字符必填手动填写产品简称字符必填手动填写产品类型字符下拉选择登记人字符系统自动记录当前登录人登记日期日期系统自动记录当前日期备注说明可爱护字段 1.5 合同转移

1.5.1 转移申请

经办人〔代办人〕差不多公布的合同信息，能够点击【移出申请】移交

给下一个人作为经办人进行后续事项的处理，转移时可填写转移说明，能够上传转移的附件到系统上。

1.5.2 转移复核

接收人在我的待办和转移复核下能够看到需要移入的合同信息列表，点击

【移入确认】，确认后经办人〔代办人〕不在有查看和修改该合同信息的权限。如原经办人〔代办人〕想再次查看需和系统治理员做申请，由系统治理员开放查看范畴后能够进行查看。

1.5.3 转出记录

经办人〔代办人〕申请移出后，系统生成一条转出记录。记录转出时

刻、转出人、转出部门、合同编号、合同名称、合同状态、转入人、转入部门。

1.5.4 转入记录

接收人移入确认后，系统生成一条转入记录。记录接收时刻、转出人、

转出部门、合同编号、合同名称、合同状态。能够链接到原合同信息。

1.6 范本治理

1.6.1 范本类型治理

➢ 功能描述名称、标识符新增合同业务类型功能描述补充说明 ➢ 数据项描述数据项名称数据类型是否必填数据来源业务类型一级字符必填手动填写名称业务类型二级字符必填手动填写名称备注说明与合同一级名称相同与合同二级名称相同 1.6.2 范本模版治理

➢ 功能描述名称、标识符新增合同范本模版功能描述补充说明 ➢ 数据项描述数据项名称数据类型业务类型一级字符名称业务类型二级字符名称范本名称字符日期日期爱护人版本号修订情形最新版本号最新爱护时刻是否生效合同范本模版字符字符字符字符日期字符是否必填数据来源必填下拉框选择必填必填必填必填必填必填必填必填必填必填下拉框选择手动填写系统默认当前日期系统默认当前登记人手动填写手动填写手动填写系统运算是/否上传附件备注说明可多次记录多个版本号说明：1、选择〝业务类型一级名称〞后可自动显示对应的〝业务类型二级名称〞。

2、每次修改都记录修订情形和最新版本号，形成多行的修改记录。 3、〝最新爱护时刻〞，每次修改版本号后系统自动记录最后的修改日期。 4、〝是否生效〞默认为〝是〞，范本模版治理员修改为〝否〞后表示差

不多失效，合同范本的模版附件不能够在下载到本地。

1.7 合同台账

通过合同台账能够查询一段时刻内所有签订合同的明细情形查询〔所有状态下的合同信息列表〕。

台账统计页面如以下图所示〔字段为参考样式〕：

➢ 功能描述名称、标识符新增合同台账功能描述补充说明 ➢ 数据项描述数据项名称数据类型标题时刻段经办部门经办人合同名称合同编号主合同名称主合同编号合同一级分类合同二级分类项目简称产品简称合同金额合同币种合同费率合同主体合同对方用印形式用印完成情形签署日期合同状态合同生效日期是否必填数据来源备注说明合同到期日期到期续签情形合同文本合同附件说明：1、统计时能够通过选择【导出的列】来定制结果中显示哪些信息。 2、能够点击结果页面的导出excel，将统计结果以excel表形式导

出到本地。

台账统计结果页面〔字段为参考样式〕：

1.8 相对方治理

新增合同公布完成会将〝合同对方〞的内容自动生成一条记录，

下次新建合同能够选择到之前生成的记录；合同对方的内容能够进行自动补全；

➢ 功能描述名称、标识符自动生成相对方信息功能描述补充说明 ➢ 数据项描述数据项名称数据类型是否必数据来源填相对方名称字符必填自动生成备注说明 1.9 档案治理

1.9.1 待复核

部门档案治理员在合同治理中点击【归档申请】后，会在档案治理【待复核】列表下自动生成一条合同信息的记录。系统档案治理员点击待复核的信息能够填写〝档案编号〔按规那么系统自动生成〕〞、〝归档日期〞、〝密级〞、〝储存期限〞、〝归档人〞、〝归档部门〞、〝备注〞等信息，填写完成点击【确认归档】按钮，合同信息自动归档到对应的经办部门下。部门档案治理员能够查看本部门已归档的全部信息。

公司档案治理员能够选择批量归档，归档需要填写的字段按照默认值生成。

1.9.2 合同档案

合同档案按照组织结构的部门进行分类。

➢ 功能描述名称、标识符合同归档功能描述补充说明 ➢ 数据项描述数据项名称数据类型是否必填数据来源部门治理员归档后系统自动生成经办人备注说明归档以后，假如做转移，经办人和经办部门不变动经办部门合同名称合同编号主合同编号主合同名称合同币种合同金额〔小写〕合同主体合同对方合同签署日期合同文本系统档案治理员确认归档时填写档案编号数值必填按照规那么系统自动生成归档份数数值必填手动填写归档日期日期必填系统档案治理员点击【确认归档】按钮后自动生成，可修改密级字符必填下拉列表框保管期限归档人归档部门题名备注字符字符字符字符字符必填必填必填下拉列表框系统运算系统运算手动填写手动填写 2021-03-HT01-0001 2 绝密、隐秘、限制，默认〝绝密〞永久、30年、10年，默认〝永久〞经办部门档案治理员即经办部门默认当前合同名称；可手动修改； 1.10 制度及公告

1.10.1 规章制度及公告公布

能够公布规章制度，并上传附件。 ➢ 功能描述名称、标识符新增规章制度、其它公告功能描述补充说明 ➢ 数据项描述数据项名称数据类型是否必填登记人字符必填登记日期字符必填标题字符必填类型字符必填正文字符必填附件附件数据来源系统生成系统生成手动填写下拉选择手动填写手动填写备注说明制度公布、公告公布 6 接口设计

接口表 AI数据同步接口 KM待办数据接口传递的数据接口方式采纳的技术 WebService WebService 抓取项目差不多信息定时待办数据实时 7 运行环境

7.1 软件平台 7.2 硬件清单

序号名称配置描述 CPU: 1 认证服务器 4Core，内存：16G ，硬盘：300G CPU: 4Core，内存：16G ，硬盘：300G 2 2 数量备注 2台虚拟机，操作系统Red Hat Enterprise Linux Server release 6.4 Linux version 2.6.32-358.el6.x86_64 ，制作群集 2台虚拟机，操作系统Red Hat Enterprise Linux Server release 6.4 Linux version 2.6.32-358.el6.x86_64 ，制作群集 2台物理机，操作系统CPU：3 应用服务器 4Core，内存：16G ，硬盘：300G 2 Red Hat Enterprise Linux Server release 6.4 Linux version 2.6.32-358.el6.x86_64 ，制作群集。 4 数据库CPU:8Core， 4 4台物理机，带光纤储备卡，操作系流程引2 擎服务器序号名称配置描述数量统备注服务器内存：32G ，硬盘：500G，HBA*2 Red Hat Enterprise Linux Server release 6.4 Linux version 2.6.32-358.el6.x86_64 ，制作RAC 5 储备高端储备总计 600G 10台机器〔6台物理机、4台虚拟机〕 7.3 软件清单

软件名称 IBM WebSphere Application Server IBM Server Oracle V8.0.0.7 V8.0.0.7 V11.2.0.3.0 Red Hat Enterprise Linux SeRedHat Linux rver release 6.4 Linux version 2.6.32-358.el6.x86_64 软件版本 7.4 数据容量估算

依照业务部门对合同治理业务需求的描述，按照每月1G的数据量估算，那么全年总共的容量约为12G，此外考虑30%的数据冗余容量，总共容量为15.6G；依照本企业对数据备份的要求，按每周3次增量备份，每月1次全备，总共储备空间将需要180G。

7.5 网络带宽估算

网络带宽估算采纳峰值并发场景进行估算，假设合同系统使用用户为1000人，平均每天大致有60%的用户即600个用户要访问该系统，关于一个典型邮件用户来说，每15分钟用户访问一次合同系统，每次访问平均交互时刻为2分钟，每天平均访问合同系统的时长是64分钟。而在一天之内，用户只有在8小时之内会使用该系统。

平均并发用户数C = nL/T，C是平均并发用户数，n是login session的数

量，L是login session的平均长度，T是值考察的时刻长度

平均并发数为600*64/(8*60〕=80 峰值并发数C’= C + 3*

即峰值并发数为：80+3*√80=107

依据我们之前的体会，每个用户平均占用带宽是100KB： 107*100Kb/1024=11MBps。

依照网络带宽利用率70%运算，那么1000个用户需要的总带宽为：

11M/70%=8Mb

8 编码规范

8.1 代码组织与风格 8.1.1 源代码文件约束

每个.java源文件内仅定义一个class，不承诺在一个.java文件内定义多个class。〔匿名内部类除外。〕

8.1.2 源代码名目

源代码名目有且仅有两个名目：src和test。src名目存放系统源代码，test名目存放单元测试源代码。专门注意：不承诺构建多个源代码名目，如此不利于

源代码的可读性。

8.1.3 源代码包结构组织

所有的项目〔产品〕的类的顶层包必须为 XXX.< 项目名称>。依照三层结构的约定，每个模块都dao、service等包。模块功能类包按照横向结构组织，即每个模块的service、dao等归属于该模块包，禁止纵向结构组织，即项目分为 service、dao等多个包，每个模块包放在service、dao之下。下面是一个典型的项目源码结构： Src XXX.ims .user .domain .dao .service .springconfig .util .view 说明项目名称模块包领域对象包数据访问层包业务层报 spring配置包模块工具包视图数据包 8.1.4 类结构

在新建一个Java类文件时，必须遵循下面的文件结构：

图〔1〕 Java类文件结构

文件注释

文件注释是用来该文件相关开发信息的，如该类的开发公司或单位、版权、作者、代码审定人、该类所支持的JDK版本、该类版本、开发日期、最后更新日期、修改人、复审人等信息。

文件注释中使用@author、@since、@version、@date等标记，方便使用jdoc等技术生成Java API标准文档。

下面确实是一个Java类的文件注释例子： /**

*开发单位：门户技术资源部 *版权：XXXX *@author：duck@XXX *@since： JDK1.4 *@version：0.0.1

*@date：2009-03-22 *最后更新日期：2009-03-23 *修改人：XXX *复审人：XXX */

包声明

所有项目代码的顶层包都应该是XXX.。例如XXX Report 报表展现平台，项目名称为report，因此顶层包应该是 XXX.report。例如： package XXX.report.domain;

引入声明

尽管Java支持用*通配符，但不承诺这么做，要求使用哪个类就单独引入哪个类。

不承诺： import java.util.*;

允许： import java.util.ArrayList;

类注释

类注释是用来说明类的实现的功能以及该类的相关类的说明。

文件注释中使用@description、@see等标记，方便使用jdoc等技术生成Java API标准文档。

下面确实是一个Java类的文件注释例子： /**

*@description :

演示Java基础语法的例子

*@see：XXX.test.Hello */

类声明

所有的类名称采纳帕斯卡表示法。如： public class HelloWorld{ }

类体元素顺序

类体中各组成元素的顺序请遵照图〔1〕所示。

注释

代码中注释是专门重要的部分。类体中的注释可分为：变量注释

包括对public、protected、default、private变量的说明。方法注释

包括对public、protected、default、private方法功能的说明。应使用〞/** */〞风格注释方便jdoc等注释工具生成文档；使用@param指令说明参数的含义；使用@throws指令说明抛出专门情形；使用@return 说明返回值的含义如： /**

* 向数据库插入一条用户数据

* @param user 要插入数据的用户对象

* @throws ServiceException 抛出由服务层抛出的专门 * @return boolean，说明是否插入成功 */

public Boolean saveUser(User user) throws ServiceException; ➢ 代码注释

方法体内部对某几条语句的说明。方法体内，每3到5行语句就应该有相应的注释。代码注释假如是单行注释，使用〝//〞进行注释，假如是多行那么使用〞/* */〞进行注释。如： //将表单参数包装到user对象中 User user = new User(); BeanUtils.populate(user,map); /*

* 从spring 应用程序环境中读取service bean， * 调用save方法，储存用户信息 */

IUserService

userService

ApplicationContextUtil.getBean(〝userService〞); userService.save(user);

8.1.5 命名

一样原那么

命名的差不多原那么是〝见名知意〞。一样地，给变量、方法和类命名时应遵循以下原那么：

➢ 使用能够准确说明命名对象含义的完整的英文描述符。

如firstName，grandTotal；不要使用x1,y1,fn如此的无意义的命名。 ➢ 采纳该领域的术语。

假如命名对象在行业中差不多有约定俗成的名称，那么不要使用其他近义词名称，如表示〝客户〞，使用Customer，而不要使用Client ➢ 少用缩写。

命名尽量不要使用简写，假如一定要使用简写，那么采纳以下原那么：  较短的单词可通过去掉〝元音〞形成缩写，例如：context，简写成

ctx；

 较长的单词可取单词的头几个字母形成缩写，例如：orgnization，

简写成org；

 一些单词有大伙儿公认的缩写，例如：Java DataBase Connection，

简写成JDBC。

➢ 在无法准确使用英文描述时才考虑使用拼音

命名规范

Java里对类、变量、方法等命名有不同的规范：

类

类名称采纳帕斯卡命名方式，每个单词的首字母大写，其他字母小写，各单词之间由大小写区分，不需要使用〝_〞。如：

public class ManagedUser{}

变量

➢ 公有静态变量

所有字母都大写，单词之间用〞_〞分割，如： public static final int MAX_COUNT = 10; ➢ 非公有静态变量

采纳表示camel法，首字母小写，名称中其他单词首字母大写。如： private static final String firstName = 〝Zhang〞; ➢ 类变量

采纳表示camel法，首字母小写，名称中其他单词首字母大写。如： private String firstName; ➢ 局部变量

采纳表示camel法，首字母小写，名称中其他单词首字母大写。如： String firstName; ➢ 方法

采纳表示camel法，首字母小写，名称中其他单词首字母大写。如：

public String getFirstName(){ return 〝zhang〞; }

8.2 代码优化 8.2.1 代码优化原那么

优化需要优化的

代码的一小部分常常占用了处理时刻的大部分，如此的代码就应该优化。不要想去优化所有的代码，甚至那些运行起来差不多专门快的代码。

代码效率不是优化的首要目标

必须在保证软件系统的正确性、稳固性、可读性及可测性的前提下，提高代码效率；不能一味地追求代码效率，而对软件的正确性、稳固性、可读性及可测性造成阻碍。

紧凑不代表高效

不要一味追求紧凑的代码，因为紧凑的代码并不代表高效的机器码，而且还降低了可读性。

8.2.2 代码优化实践

下面列举的代码优化差不多上在实践中总结出来的，并需要不断补充。

优化循环语句

➢ 减少循环嵌套的层次； ➢ 最忙的循环放在最内层；

说明：减少CPU切入循环层的次数。例如：如下代码效率不高。 for (row = 0; row < 100; row++){ for (col = 0; col < 5; col++){ sum += a[row][col]; } }

能够改为如下方式，以提高效率。 for (col = 0; col < 5; col++){ for (row = 0; row < 100; row++){ sum += a[row][col]; }

}

➢ 幸免循环体含有判定语句，应将循环体置于判定语句当中；例子：

下例效率不高：

for(int I = 0; I < array.length; i++){ } else{ } } 修改为：

if〔boolValue〕{ }

for(int I = 0; I < array.length; i++){ //program code //program code If (boolValue){ //program code

} else{ } }

for(int I = 0; I < array.length; i++){ //program code

专门的优化不要丢弃专门

对抛出的专门不应该简单进行忽略，或直截了当printStackTrace()。如此会缺失Java程序的健壮性。

既然捕捉了专门，就要对它进行适当的处理。不要捕捉专门之后又把它丢弃，不予理会。

正确处理专门的方式应该是： ➢ 处理专门。

针对该专门采取一些行动，例如修正问题、提醒某个人或进行其他一些处理，要依照具体的情形确定应该采取的动作。再次说明，调用printStackTrace算不上差不多〝处理好了专门〞。

➢ 重新抛出专门。

处理专门的代码在分析专门之后，认为自己不能处理它，重新抛出专门也不失为一种选择。

➢ 把该专门转换成另一种专门。

大多数情形下，这是指把一个低级的专门转换成应用级的专门〔其含义更容易被用户了解的专门〕。

➢ 不要捕捉专门。

catch语句中尽可能指定具体的专门类型。

在catch语句中尽可能指定具体的专门类型，必要时使用多个catch。不要试图处理所有可能显现的专门。

在finally语句块中开释资源。

专门改变了程序正常的执行流程。假如程序用到了文件、Socket、JDBC连接之类的资源，即使遇到了专门，也要正确开释占用的资源。finally块提供了如此的机会，不管是否发生专门，finally块中代码总会被执行。

因此，编写finally块应当多加小心，专门是要注意在finally块之内抛出的专门——这是执行清理任务的最后机会，尽量不要再有难以处理的错误。

说明专门的详细信息。

在显现专门时，最好能够提供一些文字信息，例如当前正在执行的类、方法和其他状态信息，包括以一种更适合阅读的方式整理和组织printStackTrace提供的信息。

尽量减小try块的体积。

分离各个可能显现专门的段落并分别捕捉其专门，而不是把大量的代码放入单个try块，然后再在catch语句中声明Exception。后面的做法为分析程序抛出专门的缘故带来了困难，因为一大段代码中有太多的地点可能抛出Exception。

幸免专门导致的输出数据不完整。

专门可能打断正常的执行流程，有可能导致输出数据的不完整，较为理想的处置方法是向输出设备写一些信息，声明数据的不完整性；另一种可能有效的方法是，先缓冲要输出的数据，预备好全部数据之后再一次性输出。

日志优化

➢ 使用Log4J日志记录工具记录日志，不要使用System.out.println去

记录日志。

➢ 开发时将Log4J的日志级别设置为DEBUG，公布时将级别设置为ERROR

8.3 SQL优化

8.3.1 提高查询效率原那么

合理利用索引

索引是数据库中重要的数据结构，它的全然目的确实是为了提高查询效率。现在大多数的数据库产品都采纳IBM最先提出的ISAM索引结构。索引的使用要恰到好处，其使用原那么如下：

 在经常进行连接，然而没有指定为外键的列上建立索引，而不经常连接

的字段那么由优化器自动生成索引。

 在频繁进行排序或分组〔即进行group by或order by操作〕的列

上建立索引。

 在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的

列上不要建立索引。比如在雇员表的〝性别〞列上只有〝男〞与〝女〞两个不同值，因此就无必要建立索引。假如建立索引不但可不能提高查询效率，反而会严峻降低更新速度。

 假如待排序的列有多个，能够在这些列上建立复合索引〔compound

index〕。

 使用系统工具。在一些数据库服务器上，索引可能失效或者因为频繁操

作而使得读取效率降低，假如一个使用索引的查询不明不白地慢下来，能够试着用工具检查索引的完整性，必要时进行修复。另外，当数据库表更新大量数据后，删除并重建索引能够提高查询速度。

幸免或简化排序

应当简化或幸免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就幸免了排序的步骤。以下是一些阻碍因素：

 索引中不包括一个或几个待排序的列；

 group by或order by子句中列的次序与索引的次序不一样；  排序的列来自不同的表。

为了幸免不必要的排序，就要正确地增建索引，合理地合并数据库表〔尽管有时可能阻碍表的规范化，但相关于效率的提高是值得的〕。假如排序不可幸免，那么应当试图简化它，如缩小排序的列的范畴等。

排除对大型表行数据的顺序存取

在嵌套查询中，对表的顺序存取对查询效率可能产生致命的阻碍。比如采纳顺序存取策略，一个嵌套3层的查询，假如每层都查询1000行，那么那个查询就要查询10亿行数据。幸免这种情形的要紧方法确实是对连接的列进行索引。例如，两个表：学生表〔学号、姓名、年龄……〕和选课表〔学号、课程号、成绩〕。假如两个表要做连接，就要在〝学号〞那个连接字段上建立索引。

还能够使用并集来幸免顺序存取。尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作：

SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008

尽管在customer_num和order_num上建有索引，然而在上面的语句中优化器依旧使用顺序存取路径扫描整个表。因为那个语句要检索的是分离的行的集合，因此应该改为如下语句：

SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001

UNION

SELECT ＊ FROM orders WHERE order_num=1008

如此就能利用索引路径处理查询。

幸免相关子查询

一个列的标签同时在主查询和where子句中的查询中显现，那么专门可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量幸免子查询。假如子查询不可幸免，那么要在子查询中过滤掉尽可能多的行。

幸免困难的正规表达式

MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配专门耗费时刻。例如：SELECT ＊ FROM customer WHERE zipcode LIKE 〝98_ _ _〞

即使在zipcode字段上建立了索引，在这种情形下也依旧采纳顺序扫描的方式。假如把语句改为SELECT ＊ FROM customer WHERE zipcode >〝98000〞，在执行查询时就会利用索引来查询，明显会大大提高速度。

另外，还要幸免非开始的子串。例如语句：SELECT ＊ FROM customer WHERE zipcode[2，3] >〝80〞，在where子句中采纳了非开始子串，因而那个语句也可不能使用索引。

使用临时表加速查询

把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于幸免多重排序操作，而且在其他方面还能简化优化器的工作。例如：

SELECT cust.name，rcvbles.balance，……other columns FROM cust，rcvbles

WHERE cust.customer_id = rcvlbes.customer_id AND rcvblls.balance>0 AND cust.postcode>〝98000〞 ORDER BY cust.name

假如那个查询要被执行多次而不止一次，能够把所有未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序：

SELECT cust.name，rcvbles.balance，……other columns FROM cust，rcvbles

WHERE cust.customer_id = rcvlbes.customer_id AND rcvblls.balance>0 ORDER BY cust.name

INTO TEMP cust_with_balance 然后以下面的方式在临时表中查询： SELECT ＊ FROM cust_with_balance WHERE postcode>〝98000〞

临时表中的行要比主表中的行少，而且物理顺序确实是所要求的顺序，减少了磁盘I/O，因此查询工作量能够得到大幅减少。

注意：临时表创建后可不能反映主表的修改。在主表中数据频繁修改的情形下，注意不要丢失数据。

8.3.2 SQL语句优化本卷须知

在编写SQL语句时，需要注意以下事项：

 ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子

句中写在最后的表(基础表)将被最先处理，在FROM子句中包含多个表的情形下,你必须选择记录条数最少的表作为基础表。

 ORACLE采纳自下而上的顺序解析WHERE子句,依照那个原理,表之间的连

接必须写在其他WHERE条件之前, 那些能够过滤掉最大数量记录的条件必须写在WHERE子句的末尾.

 幸免在索引列上使用NOT 通常，我们要幸免在索引列上使用NOT, NOT

会产生在和在索引列上使用函数相同的阻碍. 当ORACLE〞遇到〞NOT,他就会停止使用索引转而执行全表扫描.

 总是使用索引的第一个列：假如索引是建立在多个列上, 只有在它的第

一个列(leading column)被where子句引用时,优化器才会选择使用该索

引. 这也是一条简单而重要的规那么，当仅引用索引的第二个列时,优化器使用了全表扫描而忽略了索引

 假如能够的话，用EXISTS替代IN、用NOT EXISTS替代NOT IN  sql语句用大写的；因为oracle总是先解析sql语句，把小写的字母转

换成大写的再执行。

8.3.3 SQL语句查询案例

查询同样的信息，采纳不同的查询语句，查询成效将截然相反，因此在编写查询语句时需要进行查询效率测试，确保查询语句的最优化。

案例1：以下查询语句使用3237秒

select a.servnumber, substr(a.ownerorgid,1,8), to_char(b.startdate,'yyyymmdd'), to_char(b.enddate,'yyyymmdd') from subscriber a, 案例1812秒 1：同样查询成效，使用 (select subsoid,startdate,enddate from subs_service where serviceid='SELFRING' and startdate between trunc(sysdate-1) and select a.servnumber, trunc(sysdate)) b substr(a.ownerorgid,1,8) where a.active=1 from subscriber a and a.status in ('US10','US40','US364','U999') where exists(select subsoid from subs_service b where a.oid=b.subsoid and b.serviceid='SELFRING' and b.startdate between trunc(sysdate-1) and trunc(sysdate)) and a.status in ('US10','US40','US364','U999')

因篇幅问题不能全部显示，请点此查看更多更全内容

查看全文