数据库设计和编码规范Version目录简介读者对象此文档说明书供开发部全体成员阅读。

目的一个合理的数据库结构设计是保证系统性能的基础。

一个好的规范让新手容易进入状态且少犯错，保持团队支持顺畅，系统长久使用后不至于紊乱，让管理者易于在众多对象中，获取所需或理清问题。

同时，定义标准程序也需要团队合作，讨论出大家愿意遵循的规范。

随着时间演进，还需要逐步校订与修改规范，让团队运行更为顺畅。

数据库命名规范团队开发与管理信息系统讲究默契，而制定服务器、数据库对象、变量等命名规则是建立默契的基本。

命名规则是让所有的数据库用户，如数据库管理员、程序设计人员和程序开发人员，可以直观地辨识对象用途。

而命名规则大都约定俗成，可以依照公司文化、团队习惯修改并落实。

规范总体要求1.避免使用系统产品本身的惯例，让用户混淆自定义对象和系统对象或关键词。

例如，存储过程不要以sp_或xp_开头，因为SQL SERVER的系统存储过程以sp_开头，扩展存储过程以xp_开头。

2.不要使用空白符号、运算符号、中文字、关键词来命名对象。

3.名称不宜过于简略，要让对象的用途直观易懂，但也不宜过长，造成使用不方便。

4.不用为数据表内字段名称加上数据类型的缩写。

5.名称中最好不要包括中划线。

6.禁止使用[拼音]+[英语]的方式来命名数据库对象或变量。

数据库对象命名规范我们约定，数据库对象包括表、视图（查询）、存储过程（参数查询）、函数、约束。

对象名字由前缀和实际名字组成，长度不超过30。

避免中文和保留关键字，做到简洁又有意义。

前缀就是要求每种对象有固定的开头字符串，而开头字符串宜短且字数统一。

可以讨论一下对各种对象的命名规范，通过后严格按照要求实施。

例如：1.数据列参数命名格式为@+[列名称]。

示例：@EmployeeID @employee_id2.非数据列参数在参数无法跟列名称进行关联时，使用能够反映该参数功能的英文单词或单词组合,采用Pascal样式命名。

示例：@WorkType @work_type数据库设计规范好的数据库架构设计对系统运行的性能起着很大的作用，所以要在开始时就要引起重视。

为了保证数据库设计的高效必须安排时间对设计结果进行评审，这一环节必不可少。

选择有效的设计工具数据库设计工具：Power Designer、ER Studio、Rose、Microsoft Visio。

项目开始前要确定使用哪种设计工具。

(另有开发插件:RedGate系列(SQL Prompt))选择的工具要便于讨论便入生成脚本导入数据库。

设计通过后要形成文档，并且这个结构设计文档要存档，签入VSS基线库中。

在进行数据库设计时，应随时进行数据字典的维护。

(字段要求写说明)表的设计表设计在数据库设计中占据有十分重要的地位。

表是实际存储数据的对象。

除了要注重表结构设计，字段的设计之外还要注意表之间关系的设计。

遵守范式要求通常，合理的规范化会最小化数据异常和减少数据的冗余。

为了更新数据的正确与快速，在设计的初始阶段多采用三范式设计数据库表。

第一范式强调的是列的原子性，即列不能够再分成其他几列。

第二范式包含两层意思，一是表必须有一个主键；二是非主键列必须完全依赖于主键，且不能只依赖于主键的一部分。

(尽量少使用复合主键)第三范式需要确保数据表中的所有非主键列直接与主键列相关，而不能直接依赖于非主键列。

字段设计1.尽量避免可为空的列。

虽然在个别情况下，允许空值可能是有用的，但是应尽量少用。

这是因为需要对它们进行特殊处理，从而会增加数据操作的复杂性和增加CPU额外的逻辑判断。

很多情况下可以考虑用默认值0或空字符串('')来代替NULL值。

所以字段应该有NOT NULL的限制。

2.Unicode的选择。

nvarchar和nchar相应比varchar和char要占用更多的存储空间。

设计的原则是：如果确保存储的内容只是纯英文和数字，用char/varchar。

如果含有中文字符或其它多国语言，用nchar/nvarchar。

3.字段长度要精确，遵守“必须、够用”的原则。

精确的长度设计既能完整的描述数据，又可以节省存储空间。

积小成大，当数据表中的数据有很多记录的时候，这种存储空间的优势就能体现得十分明显。

存储空间越紧凑，分配的页面就越少，在同样大小的内存空间中就可以存储更多的页面，这样操作数据的效率就会提高。

例如能用char(10)的就不要用char(20),提高存储的利用率和系统性能，但同时也要兼顾扩展性和可移植性。

降低范式标准的一个重要原因是为了在检索数据时少连接表从而提供一个性能优势。

或是预先汇总计算结果并存放起来，或是将相同字段内容一式多份地放在多个表中，这样数据的冗余会增加开发人员的工作量和业务判断。

(最好是对有冗余的字段要另外用文档统一说明)完全按照规范化设计的系统几乎是不可能的，除非系统特别的小，在规范化设计后，有计划地加入冗余是必要的。

冗余可以是冗余数据库、冗余表或者冗余字段，不同粒度的冗余可以起到不同的作用。

冗余可以是为了编程方便而增加，也可以是为了性能的提高而增加。

从性能角度来说，冗余数据库可以分散数据库压力，冗余表可以分散数据量大的表的并发压力，也可以加快特殊查询的速度，冗余字段可以有效减少数据库表的连接，提高效率。

数据库设计阶段，对必要的冗余处理可以事先安排设计，如果在代码实现阶段发现一些必要的冗余字段可以及早提出来考虑。

注意大类型的字段设计如果设计过程中发现表中存在大类型(可存储2G)的字段时，要慎重考虑，因为这样的字段会造成单一数据页存放不了几条记录。

而过多的页面也会在查询扫描时带来性能影响。

一般的做法是将XML、IMAGE、VARCHAR(MAX)、NVARCHAR(MAX)或TEXT 类型的字段切割到另外的数据表，而后与主数据表一对一连接。

因为这些大型数据访问缓慢，修改时可能造成记录锁定较久。

且在大多数的使用状态下，查询一般字段内容时可能根本用不到这些字段。

这些列的存在会增加表的页面数，不分割出去容易会影响其它字段的修改和查询。

VARCHAR(MAX)、NVARCHAR(MAX)字段如果实际长度在8000以下，这个值将被作为常规的变长数据类型来对待，如果超过8000个字节，SQL Server将该值作为TEXT来存储处理。

如果该表数据量比较大时，一定要考虑大字段分离设计原则。

少用TEXT和IMAGE，二进制字段的读写是比较慢的。

表关系和约束设计正确处理表间关系。

一对多、一对一、多对多等关系。

主外键关系是保证数据完整性的一个重要机制。

维护数据的正确性。

尽量采用提供的约束，如主外键、检查、默认值、不可NULL等。

尽可能不要通过程序或存储过程、触发器等机制来运行，毕竟SQLSERVER约束是在内部以优化过的二进制程序代码来实现的，而其它方式效率当然不如直接设置的约束高。

还有，能够确定具有唯一值的字段上尽量加上唯一性约束。

一些约束在客户端判断的确是可以减少服务器的资源，但是不能完全保证数据的错误产生。

而且用数据库使用域和参照完整性有时候还能帮助优化器减少查询执行时间。

域和参照完整性帮助优化器分析有效的数据值而不需要物理访问数据，这减少了查询时间。

主键设计所有的表必须设置主键。

主键跟聚焦索引没有什么关系,但主键必须要有索引。

主键的选择原则：1.字段值唯一。

2.不可NULL。

3.字段大小尽量最小。

4.字段值不常变更。

5.不建议用复合主键。

主健值过大会影响外健数据表的大小。

如果主键是聚集索引，由于所有非聚集索引都会存储聚集索引的键值，所以主键值过大，还将导致其他索引结构的效率不佳（页面数）。

主键关乎着数据的正确性与完整性。

而聚焦索引是从数据的运行效率出发。

虽然主键跟聚集索引是两回事，但基于主键的上述特性，所以主键往往适合作为表的聚集索引，这也是微软的默认做法。

但一些没有意义的ID做聚集索引的意义不大，这时候需要在创建表的时候给主键指定为唯一的非聚集索引。

-- 主键约束(非聚集索引)：ALTER TABLE[dbo].[TCustomer]ADD CONSTRAINT PK_TCustomer PRIMARY KEY NONCLUSTERED (ID);选择GUID做为主键时在系统对接、移值和代码编写下都提供了很大的方便，但它是建立在牺牲性能的基础上。

在实际运用中，如果对于用36字符的GUID当作主键时，应当注意的问题如下：1.GUID是无序的，所以不适合用来做聚集索引。

否则会引起频繁的页面移动而产生大量的碎片。

2.GUID类型的存储可以由char(36)改为uniqueidentifier类型（16个字节），以节省存储空间。

3.对于有关联的表之间，考虑程序方便可用使用GUID做为主键，但对于独立的表，还是以INT类型的字段做为主键来设计。

所以设计阶段要分清哪些必须用GUID来做主键。

外键设计外键的存在会在处理数据时带来麻烦，但实际上这点恰恰是它的好处。

外键的存在就最高效的一致性维护方法。

所以在表设计时要考虑主外键的设计。

如果决定使用外键约束，那么所有人必须遵守严格执行。

外键是最高效的一致性维护方法，数据库的一致性要求，依次可以用外键、CHECK约束、规则约束、触发器、客户端程序，一般认为，离数据越近的方法效率越高。

检查约束约束除了主外键约束、唯一性约束和默认值约束外，还有一类叫检查约束。

检查约束是一个识别SQLServer表中每行可接受的列值的规则，检查约束帮助实施域的完整性，域完整性定义了数据库表中列的有效值，检查约束可以验证单列的域完整性，也可以验证多列的域完整性，在单个列上可以有多个检查约束，如果插入或更新的数据违反了检查约束，数据库引擎将暂时停止INSERT和UPDATE操作。

CREATE TABLE(ID INT,Code VARCHAR(20),Sex CHAR(1)CONSTRAINT Text_Sex_CK CHECK (Sex ='F'OR Sex ='M'),-- Sex列创建相应的约束，其值只能是'F'或'M'值。

Experience INT CONSTRAINT Text_Experience_CK CHECK (Experience >= 0)-- Experience列创建相应的约束，其值必须>=0);索引的设计索引是一把双刃剑，它通常可以加快数据检索数据的同时，往往又会带来额外的资源开销（在insert、update和delete使用时）。

有时候这个开销代价甚至超过了查询优化带来的好处。

所以，索引的创建是门艺术，要在工作中不断的积累经验和不断的总结。

一般来说，建立索引要看数据使用的方式，也就是说那些访问数据的SQL语句经常使用，针对这些经常使用的SQL语句创建有效的索引还是值得的，但过多的索引又是对于OLTP（在线事务）数据库是不利的。