DataBase编码规范.docx

Stag Java编码规范深圳市施泰信息技术有限公司Stag数据库开发规范Stag Database Coding SpecificationVersion1.0Kat2014/9/28编程不是艺术，而是一项工程活动。对于任何工程项目来说，统一的施工标准都是保证工程质量的重要因素。高品质、易维护的软件开发离不开清晰明确的编码规范。修订历史修改人修改内容时间版本号Kat起草、编写2014.9.28Ver 1.0目录1 概述31.1 权威性31.2 开放性31.3 规范内容31.4 适用范围31.5 制定原则31.6 阅读导引41.7 实施42 数据库命名规范52.1 数据库命名53 数据库设计规范73.1 库表结构设计71 概述对于任何工程项目来说，统一的施工标准都是保证工程质量的重要因素。堪称当今人类最抽象、最复杂的工程软件工程，自然更加不能例外。高品质、易维护的软件开发离不开清晰严格的编码规范。使代码易于管理的方法之一是加强代码一致性让任何程序员都可以快速读懂你的代码。保持统一编程风格并遵守约定意味着可以很容易根据“模式匹配”规则来推断各种标识符的含义。创建通用的、必需的习惯用语和模式可以使代码更容易理解。1.1 权威性您可能不认同本规范的某些内容，尤其是关于代码风格和命名约定，业界本身就有不同的流派，如同设计一般，没有谁对谁错。但是，在您看到本规范前，项目中已经有很多代码是这样写了。在某些情况下可能有充分的甚至强烈的理由改变某些编程风格，但我们还是应该遵循一致性原则，所以要求：必须严格遵守本规范的每一条约定！1.2 开放性本规范是权威的，同时也是开放的。在遵守本规范约定的前提下，您可以对本规范提出不同的意见和想法。本规范欢迎所有合理的提议，并保持自身的更新。1.3 规范内容本规范不仅列出你要怎么做，还告诉你为什么要这么做，哪些情况下可以不这么做，以及如何权衡其利弊。1.4 适用范围软件开发中数据库的设计1.5 制定原则规则的作用就是避免混乱。但规则本身一定要权威，有说服力，并且是理性的。本规范在制定过程中，尽量遵循合理性、普遍性原则，以符合绝大多数程序员的编程风格，这一点对于流动性较大的团队尤其适合。综观各公司或项目的编码规范，有些是条条框框限制得详细致尽，有些则是粗枝大叶阐述得令人费解，而有些甚至是武断粗暴得使人不舒服。本规范企图从严谨性和自由度两方面做一个合理的权衡。随着现代IDE的智能化发展和自动化文档工具的出现，很多以前的编码风格（比如类型前缀）可能不再适合新时代的编程活动，本规范将考虑这一点。本规范的制定原则列举如下（按优先级别排序）：l 同一性：在总体方向上保持一致，这是最大的原则l 普遍性：尽量符合绝大多数程序员的使用习惯l 简洁性：忽略无关紧要的细节和差异性，以减少程序员的学习负担l 新颖性：规范本身保持发展，以适应不断发展的软件工程思想和编程环境1.6 阅读导引本文档中的规范分为两类：强制性规范和建议性规范。强制性规范必须严格实行，没有例外或者少有例外；建议性规范的强制性稍微弱一点，一般情况下仍要遵守，但在某些情况下可略微放宽。强制性规范条目使用实线方框，建议性规范条目使用虚拟方框，下面是一条建议性规范：定义函数时，参数顺序依次为：输入参数、输出参数。本文档列出的每条规范，一般都包括：l 规范标题：以三级标题列出的内容，如：3.1.2 行长度限制l 规范条目：以线框标注的内容，简洁准确描述了需要遵守的规则，如：每一行代码字符数不要超过80l 规范描述：在规范条目下方，对条目中的规则作进一步说明，如对规则制定的原因、规则本身的解析等有些规范还包括：l 规范示例：列举示范代码，举例说明哪些代码是符合规范的，哪些是不符合规范的l 规范特例：在某些情况下，可以不按当前规则编码对于编程经验偏少的新手，建议按顺序全文细读所有规范文本；对于经验丰富的老手，仅需要浏览每条规范标题和条目即可，遇到不清晰的条目时再详细阅读规范描述和剩余说明。1.7 实施为了更好地贯彻实施本规范，需要切实可行的审查制度。下面列出了有效的实施方法，可根据需要执行：l 设立代码审查小组：设立专门的代码审查小组，对项目的所有源码进行有计划的审查和评估。l 设立交叉审查制度：程序员间设立源码的交叉审查制度，鼓励大家互相督促。l 设立奖惩和激励机制：设立优先程序员荣誉称号，定期评选并给予一定的物质奖励；对于屡次范错，指出后仍不遵守的，给予项目组内公开批评。为了提高审查与自我检查的效率和精度，以后将提供专门的自动化检查工具，以IDE插件和独立应用程序的形式提供专门的自动化批量代码检查工具。2 数据库命名规范2.1 数据库命名由于项目性质、规模上存在着差异，不同项目间的数据库差别很大。但文件、组织结构的基本原则应当是一致的。具体细节请参考相关的版本控制规范。2.1.1 基本规则名称中词与词之间用下划线“_”作分隔符。统一使用大小写。例如：customer_id2.1.2 表表的命名以实体名称命名，以“t_”作为前缀。由于表是数据库中最常用的对象，因此表的命名以实体名称命名即可，例如：客户表的表名为“t_customer”，产品表的表名为“t_product”。2.1.3 视图视图的名称以“v_”作为前缀。若视图仅针对一个表，则在前缀“v_”后接表名，若是多个表则前缀“v_”后接表名，表名之间以下划线“_”分隔。例如：欠费客户清单视图的名称为“v_notpaycust”。欠费客户清单视图的名称为“v_customer_notpay”。2.1.4 索引索引的名称以“i_”作为前缀。若该表仅有一个索引或该索引是主键索引，则前缀后接表名即可。对于其他索引，表名后接字段名，中间用下划线“_”分隔。例如：客户表索引的名称为“i_customer”。客户类型索引的名称为“i_customer_type”，客户类型年龄索引的名称为“i_customer_type_age”。2.1.5 触发器触发器的名称以“tri_”作为前缀，后接表名、触发时间和被触发的事件，中间以下划线“_”作为分隔符。例如：用户表id自增长的触发器的名称为“tri_insert_id”。2.1.6 字段字段名以实体属性的（英文）全称命名。若名称含多个词可用下划线“_”作分隔符。若名称太长可使用缩写。同一实体属性在不同表中应使用相同的名称。例如： “客户号”的字段名为“customer_id”办公室电话”的字段名为“office_phone”“产品过期日”的字段名为“prod_exp_date”3 数据库设计规范3.1 库表结构设计库表结构包含每个库表的详细字段描述，是应用系统数据库设计的关键。应用系统的每个库表应单独填制一张库表结构描述表。库表结构描述表中包含的主要项目有：表名、所属子系统、表描述、表使用方式、表约束、字段名、字段中文名称、字段类型、字段长度、字段约束、字段描述、字段缺省值、字段取值范围、备注等。3.1.1 库表编码格式数据库本身和表的的编码格式统一为UTF-8源码文件统一使用Unicode编码，这样即使文件中使用了非ASCII字符（如中文），也能在不同的编辑器和操作系统中，保证非ASCII字符不会乱码。3.1.2 语句单词大小写数据库系统保留字用大写，其他字用小写。例如：SELECT * FROM users 3.1.3 缩进每个字段占据一行，且缩进一个制表符。例如：CREATETABLEcustomer(idINTEGERNOTNULL,nameVARCHAR2(8)NOTNULL,agenumberNOTNULL,salaryMONEYDEFAULT100.00,addressVARCHAR2(30),.)3.1.4 对齐字段的各描述项的首字母按列对齐。3.1.5 字段注释若提供字段的注释，则注释在字段描述行的下面单独占据一行，且缩进两个制表符。例如：addressVARC