关键字: 数据库建表原则

·1. 原始单据与实体之间的关系

可以是一对一、一对多、多对多的关系。在一般情况下，它们是一对一的关系：即一张原始单据对应且只对应一个实体。在特殊情况下，它们可能是一对多或多对一的关系，即一张原始单证对应多个实体，或多张原始单证对应一个实体。这里的实体可以理解为基本表。明确这种对应关系后，对我们设计录入界面大有好处。

〖例〗：一份员工履历资料，在人力资源信息系统中，就对应三个基本表：员工基本情况表、社会关系表、工作简历表。这就是“一张原始单证对应多个实体”的典型例子。

·2. 主键与外键

一般而言，一个实体不能既无主键又无外键。在E—R 图中, 处于叶子部位的实体, 可以定义主键，也可以不定义主键(因为它无子孙), 但必须要有外键(因为它有父亲)。

主键与外键的设计，在全局数据库的设计中，占有重要地位。当全局数据库的设计完成以后，有个美国数据库设计专家说：“键，到处都是键，除了键之外，什么也没有”，这就是他的数据库设计经验之谈，也反映了他对信息系统核心(数据模型)的高度抽象思想。因为：主键是实体的高度抽象，主键与外键的配对，表示实体之间的连接。

·3. 基本表的性质

基本表与中间表、临时表不同，因为它具有如下四个特性：

(1) 原子性。基本表中的字段是不可再分解的。

(2) 原始性。基本表中的记录是原始数据（基础数据）的记录。

(3) 演绎性。由基本表与代码表中的数据，可以派生出所有的输出数据。

(4) 稳定性。基本表的结构是相对稳定的，表中的记录是要长期保存的。

理解基本表的性质后，在设计数据库时，就能将基本表与中间表、临时表区分开来。

·4. 范式标准

基本表及其字段之间的关系, 应尽量满足第三范式。但是，满足第三范式的数据库设计，往往不是最好的设计。为了提高数据库的运行效率，常常需要降低范式标准：适当增加冗余，达到以空间换时间的目的。

〖例〗：有一张存放商品的基本表，如表1所示。“金额”这个字段的存在，表明该表的设计不满足第三范式，因为“金额”可以由“单价”乘以“数量”得到，说明“金额”是冗余字段。但是，增加“金额”这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。

在Rose 2002中，规定列有两种类型：数据列和计算列。“金额”这样的列被称为“计算列”，而“单价”和“数量”这样的列被称为“数据列”。

表1 商品表的表结构

商品名称  商品型号  单价  数量   金额

电视机    29吋      2,500  40  100,000

·5. 通俗地理解三个范式

通俗地理解三个范式，对于数据库设计大有好处。在数据库设计中，为了更好地应用三个范式，就必须通俗地理解三个范式(通俗地理解是够用的理解，并不是最科学最准确的理解)：

第一范式：1NF是对属性的原子性约束，要求属性具有原子性，不可再分解；

第二范式：2NF是对记录的惟一性约束，要求记录有惟一标识，即实体的惟一性；

第三范式：3NF是对字段冗余性的约束，即任何字段不能由其他字段派生出来，它要求字段没有冗余.

没有冗余的数据库设计可以做到。但是，没有冗余的数据库未必是最好的数据库，有时为了提高运行效率，就必须降低范式标准，适当保留冗余数据。具体做法是：在概念数据模型设计时遵守第三范式，降低范式标准的工作放到物理数据模型设计时考虑。降低范式就是增加字段，允许冗余。

·6. 要善于识别与正确处理多对多的关系

若两个实体之间存在多对多的关系，则应消除这种关系。消除的办法是，在两者之间增加第三个实体。这样，原来一个多对多的关系，现在变为两个一对多的关系。要将原来两个实体的属性合理地分配到三个实体中去。这里的第三个实体，实质上是一个较复杂的关系，它对应一张基本表。一般来讲，数据库设计工具不能识别多对多的关系，但能处理多对多的关系。

〖例〗：在“图书馆信息系统”中，“图书”是一个实体，“读者”也是一个实体。这两个实体之间的关系，是一个典型的多对多关系：一本图书在不同时间可以被多个读者借阅，一个读者又可以借多本图书。为此，要在二者之间增加第三个实体，该实体取名为“借还书”，它的属性为：借还时间、借还标志(0表示借书，1表示还书)，另外，它还应该有两个外键(“图书”的主键，“读者”的主键)，使它能与“图书”和“读者”连接。

·7. 主键PK的取值方法

PK是供程序员使用的表间连接工具，可以是一无物理意义的数字串, 由程序自动加1来实现。也可以是有物理意义的字段名或字段名的组合。不过前者比后者好。当PK是字段名的组合时，建议字段的个数不要太多，多了不但索引占用空间大，而且速度也慢。

·8. 正确认识数据冗余

主键与外键在多表中的重复出现,不属于数据冗余，这个概念必须清楚，事实上有许多人还不清楚。非键字段的重复出现, 才是数据冗余！而且是一种低级冗余，即重复性的冗余。高级冗余不是字段的重复出现，而是字段的派生出现。

〖例〗：商品中的“单价、数量、金额”三个字段，“金额”就是由“单价”乘以“数量”派生出来的，它就是冗余，而且是一种高级冗余。冗余的目的是为了提高处理速度。只有低级冗余才会增加数据的不一致性，因为同一数据，可能从不同时间、地点、角色上多次录入。因此，我们提倡高级冗余(派生性冗余)，反对低级冗余(重复性冗余)。

消费流水表的 原余额，现余额，消费金额其中原余额冗余 ，但是也要保留。

·9. E--R图没有标准答案

信息系统的E--R图没有标准答案，因为它的设计与画法不是惟一的，只要它覆盖了系统需求的业务范围和功能内容，就是可行的。反之要修改E--R图。尽管它没有惟一的标准答案，并不意味着可以随意设计。好的E—R图的标准是：结构清晰、关联简洁、实体个数适中、属性分配合理、没有低级冗余。

·10. 视图技术在数据库设计中很有用

与基本表、代码表、中间表不同，视图是一种虚表，它依赖数据源的实表而存在。视图是供程序员使用数据库的一个窗口，是基表数据综合的一种形式, 是数据处理的一种方法，是用户数据保密的一种手段。为了进行复杂处理、提高运算速度和节省存储空间, 视图的定义深度一般不得超过三层。 若三层视图仍不够用, 则应在视图上定义临时表, 在临时表上再定义视图。这样反复交迭定义, 视图的深度就不受限制了。

对于某些与国家政治、经济、技术、军事和安全利益有关的信息系统，视图的作用更加重要。这些系统的基本表完成物理设计之后，立即在基本表上建立第一层视图，这层视图的个数和结构，与基本表的个数和结构是完全相同。并且规定，所有的程序员，一律只准在视图上操作。只有数据库管理员，带着多个人员共同掌握的“安全钥匙”，才能直接在基本表上操作。请读者想想：这是为什么？

·11. 中间表、报表和临时表

中间表是存放统计数据的表，它是为数据仓库、输出报表或查询结果而设计的，有时它没有主键与外键(数据仓库除外)。临时表是程序员个人设计的，存放临时记录，为个人所用。基表和中间表由DBA维护，临时表由程序员自己用程序自动维护。

·12. 完整性约束表现在三个方面

域的完整性：用Check来实现约束，在数据库设计工具中，对字段的取值范围进行定义时，有一个Check按钮，通过它定义字段的值城。参照完整性：用PK、FK、表级触发器来实现。用户定义完整性：它是一些业务规则，用存储过程和触发器来实现。

·13. 防止数据库设计打补丁的方法是“三少原则”

(1) 一个数据库中表的个数越少越好。只有表的个数少了，才能说明系统的E--R图少而精，去掉了重复的多余的实体，形成了对客观世界的高度抽象，进行了系统的数据集成，防止了打补丁式的设计；

(2) 一个表中组合主键的字段个数越少越好。因为主键的作用，一是建主键索引，二是做为子表的外键，所以组合主键的字段个数少了，不仅节省了运行时间，而且节省了索引存储空间；

(3) 一个表中的字段个数越少越好。只有字段的个数少了，才能说明在系统中不存在数据重复，且很少有数据冗余，更重要的是督促读者学会“列变行”，这样就防止了将子表中的字段拉入到主表中去，在主表中留下许多空余的字段。所谓“列变行”，就是将主表中的一部分内容拉出去，另外单独建一个子表。这个方法很简单，有的人就是不习惯、不采纳、不执行。

数据库设计的实用原则是：在数据冗余和处理速度之间找到合适的平衡点。“三少”是一个整体概念，综合观点，不能孤立某一个原则。该原则是相对的，不是绝对的。“三多”原则肯定是错误的。试想：若覆盖系统同样的功能，一百个实体(共一千个属性) 的E--R图，肯定比二百个实体(共二千个属性) 的E--R图，要好得多。

提倡“三少”原则，是叫读者学会利用数据库设计技术进行系统的数据集成。数据集成的步骤是将文件系统集成为应用数据库，将应用数据库集成为主题数据库，将主题数据库集成为全局综合数据库。集成的程度越高，数据共享性就越强，信息孤岛现象就越少，整个企业信息系统的全局E—R图中实体的个数、主键的个数、属性的个数就会越少。

提倡“三少”原则的目的，是防止读者利用打补丁技术，不断地对数据库进行增删改，使企业数据库变成了随意设计数据库表的“垃圾堆”，或数据库表的“大杂院”，最后造成数据库中的基本表、代码表、中间表、临时表杂乱无章，不计其数，导致企事业单位的信息系统无法维护而瘫痪。

“三多”原则任何人都可以做到，该原则是“打补丁方法”设计数据库的歪理学说。“三少”原则是少而精的原则，它要求有较高的数据库设计技巧与艺术，不是任何人都能做到的，因为该原则是杜绝用“打补丁方法”设计数据库的理论依据。

·14. 提高数据库运行效率的办法

在给定的系统硬件和系统软件条件下，提高数据库系统的运行效率的办法是：

(1) 在数据库物理设计时，降低范式，增加冗余, 少用触发器, 多用存储过程。

(2) 当计算非常复杂、而且记录条数非常巨大时(例如一千万条)，复杂计算要先在数据库外面，以文件系统方式用C++语言计算处理完成之后，最后才入库追加到表中去。这是电信计费系统设计的经验。

(3) 发现某个表的记录太多，例如超过一千万条，则要对该表进行水平分割。水平分割的做法是，以该表主键PK的某个值为界线，将该表的记录水平分割为两个表。若发现某个表的字段太多，例如超过八十个，则垂直分割该表，将原来的一个表分解为两个表。

(4) 对数据库管理系统DBMS进行系统优化，即优化各种系统参数，如缓冲区个数。

(5) 在使用面向数据的SQL语言进行程序设计时，尽量采取优化算法。

总之，要提高数据库的运行效率，必须从数据库系统级优化、数据库设计级优化、程序实现级优化，这三个层次上同时下功夫。

上述十四个技巧，是许多人在大量的数据库分析与设计实践中，逐步总结出来的。对于这些经验的运用，读者不能生帮硬套，死记硬背，而要消化理解，实事求是，灵活掌握。并逐步做到：在应用中发展，在发展中应用。

本文来自CSDN博客，转载请标明出处：

http://blog.csdn.net/lovegod12/archive/2009/03/13/3986346.aspx

SQL数据库建表前期优化

关于数据库优化方面的文章很多，但是有的写的似是而非，有的不切实际，对一个数据库来说，只能做到更优，不可能最优，并且由于实际需求不同，优化方案还是有所差异，根据实际需要关心的方面（速度、存储空间、可维护性、可拓展性）来优化数据库，而这些方面往往又是相互矛盾的，下面结合网上的一些看法和自己的一些观点做个总结。

　　一个系统的性能的提高，不单单是试运行或者维护阶段的性能调优，也不单单是开发阶段的事情，而是在整个软件生命周期都需要注意。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。

　　一、 分析阶段

　　一般来说，在系统分析阶段往往有太多需要关注的地方，系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力，但是，我们必须注意，性能是很重要的非功能性需求，必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能有各种需求的量化的指标。

　　另一方面，在分析阶段应该根据各种需求区分出系统的类型，大的方面，区分是OLTP(联机事务处理系统)和OLAP(联机分析处理系统)。

　　二、 设计阶段

　　设计阶段可以说是以后系统性能的关键阶段，在这个阶段，有一个关系到以后几乎所有性能调优的过程—数据库设计。

　　在数据库设计完成后，可以进行初步的索引设计，好的索引设计可以指导编码阶段写出高效率的代码，为整个系统的性能打下良好的基础。

　　以下是性能要求设计阶段需要注意的：

　　1、数据库逻辑设计的规范化

　　数据库逻辑设计的规范化就是我们一般所说的范式，我们可以这样来简单理解范式：

　　第1规范：没有重复的组或多值的列，这是数据库设计的最低要求。

第2规范: 每个非关键字段必须依赖于主关键字，不能依赖于一个组合式主关键字的某些组成部分。消除部分依赖，大部分情况下，数据库设计都应该达到第二范式。

　　第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖，达到第三范式应该是系统中大部分表的要求，除非一些特殊作用的表。

　　更高的范式要求这里就不再作介绍了，个人认为，如果全部达到第二范式，大部分达到第三范式，系统会产生较少的列和较多的表，因而减少了数据冗余，也利于性能的提高。

　　2、合理的冗余

　　完全按照规范化设计的系统几乎是不可能的，除非系统特别的小，在规范化设计后，有计划地加入冗余是必要的。

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

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

　　3、主键的设计

　　主键是必要的，SQLSERVER的主键同时是一个唯一索引，而且在实际应用中，我们往往选择最小的键组合作为主键，所以主键往往适合作为表的聚集索引。聚集索引对查询的影响是比较大的，这个在下面索引的叙述。

　　在有多个键的表，主键的选择也比较重要，一般选择总的长度小的键，小的键的比较速度快，同时小的键可以使主键的B树结构的层次更少。

　　主键的选择还要注意组合主键的字段次序，对于组合主键来说，不同的字段次序的主键的性能差别可能会很大，一般应该选择重复率低、单独或者组合查询可能性大的字段放在前面。

　　4、外键的设计

外键作为数据库对象，很多人认为麻烦而不用，实际上，外键在大部分情况下是很有用的，理由是：

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

　　谨慎使用级联删除和级联更新，级联删除和级联更新作为SQL SERVER 2000当年的新功能，在2005作 了保留，应该有其可用之处。我这里说的谨慎，是因为级联删除和级联更新有些突破了传统的关于外键的定义，功能有点太过强大，使用前必须确定自己已经把握好其功能范围，否则，级联删除和级联更新可能让你的数据莫名其妙的被修改或者丢失。从性能看级联删除和级联更新是比其他方法更高效的方法。

　　5、字段的设计

　　字段是数据库最基本的单位，其设计对性能的影响是很大的。需要注意如下：

　　A、数据类型尽量用数字型，数字型的比较比字符型的快很多。

　　B、数据类型尽量小，这里的尽量小是指在满足可以预见的未来需求的前提下的。

　　C、尽量不要允许NULL，除非必要，可以用NOT NULL+DEFAULT代替。

　　D、少用TEXT和IMAGE，二进制字段的读写是比较慢的，而且，读取的方法也不多，大部分情况下最好不用。

　　E、自增字段要慎用，不利于数据迁移。

　　6、数据库物理存储和环境的设计

　　在设计阶段，可以对数据库的物理存储、操作系统环境、网络环境进行必要的设计，使得我们的系统在将来能适应比较多的用户并发和比较大的数据量。

　　这里需要注意文件组的作用，适用文件组可以有效把I/O操作分散到不同的物理硬盘，提高并发能力。

　　7、系统设计

　　整个系统的设计特别是系统结构设计对性能是有很大影响的，对于一般的OLTP系统，可以选择C/S结构、三层的C/S结构等，不同的系统结构其性能的关键也有所不同。

系统设计阶段应该归纳一些业务逻辑放在数据库编程实现，数据库编程包括数据库存储过程、触发器和函数。用数据库编程实现业务逻辑的好处是减少网络流量并可更充分利用数据库的预编译和缓存功能。

　　8、索引的设计

　　在设计阶段，可以根据功能和性能的需求进行初步的索引设计，这里需要根据预计的数据量和查询来设计索引，可能与将来实际使用的时候会有所区别。

　　关于索引的选择，应该主意：

　　A、根据数据量决定哪些表需要增加索引，数据量小的可以只有主键。

　　B、根据使用频率决定哪些字段需要建立索引，选择经常作为连接条件、筛选条件、聚合查询、排序的字段作为索引的候选字段。字段(列)允许为空一般来说不建立索引。

　　C、把经常一起出现的字段组合在一起，组成组合索引，组合索引的字段顺序与主键一样，也需要把最常用的字段放在前面，把重复率低的字段放在前面。

D、一个表不要加太多索引，因为索引影响插入和更新的速度。

本篇文档来自：

http://hi.baidu.com/zhnantz/blog/item/2349a1019be1a9c7277fb5b5.html

SQL数据库操作优化

1.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num is null

可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：

select id from t where num=0

2.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。优化器将无法通过索引来确定将要命中的行数,因此需要搜索该表的所有行。

3.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：

select id from t where num=10 or num=20

可以这样查询：

select id from t where num=10

union all

select id from t where num=20

4.in和 not in 也要慎用，因为IN会使系统无法使用索引,而只能直接搜索表中的数据。如：

select id from t where num in(1,2,3)

对于连续的数值，能用 between 就不要用 in 了：

select id from t where num between 1 and 3

5.尽量避免在索引过的字符数据中，使用非打头字母搜索。这也使得引擎无法利用索引。

见如下例子：

SELECT * FROM T1 WHERE NAME LIKE ‘%L%’  --搜索含有L的

SELECT * FROM T1 WHERESUBSTING(NAME,2,1)=’L’

SELECT * FROM T1 WHERE NAME LIKE ‘L%’    --搜索开头是L的

即使NAME字段建有索引，前两个查询依然无法利用索引完成加快操作，引擎不得不对全表所有数据逐条操作来完成任务。而第三个查询能够使用索引来加快操作。

6.必要时强制查询优化器使用某个索引，如在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：

select id from t where num=@num

可以改为强制查询使用索引：

select id from t with(index(索引名)) where num=@num

7.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。尽量使用列名=表达式。如：

SELECT * FROM T1 WHERE F1/2=100

应改为:

SELECT * FROM T1 WHERE F1=100*2

SELECT * FROM RECORD WHERESUBSTRING(CARD_NO,1,4)=’5378’

应改为:

SELECT * FROM RECORD WHERE CARD_NO LIKE‘5378%’

SELECT member_number, first_name, last_nameFROM members

WHERE DATEDIFF(yy,datofbirth,GETDATE())> 21

应改为:

SELECT member_number, first_name, last_nameFROM members

WHERE dateofbirth <DATEADD(yy,-21,GETDATE())

即：任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。

8.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：

select id from t wheresubstring(name,1,3)='abc'--name以abc开头的id

select id from t wheredatediff(day,createdate,'2005-11-30')=0--‘2005-11-30’生成的id

应改为:

select id from t where name like 'abc%'

select id from t wherecreatedate>='2005-11-30' and createdate<'2005-12-1'

9.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。

10.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。

11.很多时候用 exists是一个好的选择，尽量用exists代替in：

select num from a where num in(select numfrom b)

用下面的语句替换：

select num from a where exists(select 1from b where num=a.num)

SELECT SUM(T1.C1)FROM T1 WHERE(

(SELECT COUNT(*)FROM T2 WHERET2.C2=T1.C2>0)

用下面的语句替换：

SELECT SUM(T1.C1) FROM T1WHERE EXISTS(

SELECT * FROM T2 WHERE T2.C2=T1.C2)

两者产生相同的结果，但是后者的效率显然要高于前者。因为后者不会产生大量锁定的表扫描或是索引扫描。

如果你想校验表里是否存在某条纪录，不要用count(*)那样效率很低，而且浪费服务器资源。可以用EXISTS代替。如：

IF (SELECT COUNT(*) FROM table_name WHEREcolumn_name = 'xxx')

可以写成：

IF EXISTS (SELECT * FROM table_name WHEREcolumn_name = 'xxx')

经常需要写一个T_SQL语句比较一个父结果集和子结果集，从而找到是否存在在父结果集中有而在子结果集中没有的记录，如：

SELECT a.hdr_key FROM hdr_tbl a---- tbl a 表示tbl用别名a代替

WHERE NOT EXISTS (SELECT * FROM dtl_tbl bWHERE a.hdr_key = b.hdr_key)

SELECT a.hdr_key FROM hdr_tbl a

LEFT JOIN dtl_tbl b ON a.hdr_key =b.hdr_key WHERE b.hdr_key IS NULL

SELECT hdr_key FROM hdr_tbl

WHERE hdr_key NOT IN (SELECT hdr_key FROMdtl_tbl)

三种写法都可以得到同样正确的结果，但是效率依次降低。

效率：exists>inner(left,right)join>in

12.尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。

13.避免频繁创建和删除临时表，以减少系统表资源的消耗。

14.临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。

15.在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先createtable，然后insert。

16.如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table TableName，然后 drop tableTableName，这样可以避免系统表的较长时间锁定。

17.在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。

18.尽量避免大事务操作，提高系统并发能力。

19.尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。

20. 避免使用不兼容的数据类型。例如float和int、char和varchar、binary和varbinary是不兼容的。数据类型的不兼容可能使优化器无法执行一些本来可以进行的优化操作。例如:

SELECTname FROM employee WHERE salary > 60000

在这条语句中,如salary字段是money型的,则优化器很难对其进行优化,因为60000是个整型数。我们应当在编程时将整型转化成为钱币型,而不要等到运行时转化。

21.充分利用连接条件，在某种情况下，两个表之间可能不只一个的连接条件，这时在 WHERE 子句中将连接条件完整的写上，有可能大大提高查询速度。

例：

SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD BWHERE A.CARD_NO = B.CARD_NO

SELECT SUM(A.AMOUNT) FROM ACCOUNT A,CARD BWHERE A.CARD_NO = B.CARD_NO AND A.ACCOUNT_NO=B.ACCOUNT_NO

第二句将比第一句执行快得多。

22、使用视图加速查询

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

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

如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个视图中，并按客户的名字进行排序：

CREATE VIEW DBO.V_CUST_RCVLBES

AS

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

然后以下面的方式在视图中查询：

SELECT ＊ FROM V_CUST_RCVLBES

WHERE postcode>“98000”

视图中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。

23、能用DISTINCT的就不用GROUP BY

SELECT OrderID FROM Details WHERE UnitPrice> 10 GROUP BY OrderID

可改为：

SELECT DISTINCT OrderID FROM Details WHEREUnitPrice > 10

24.能用UNION ALL就不要用UNION

UNION ALL不执行SELECT DISTINCT函数，这样就会减少很多不必要的资源。

25.尽量不要用SELECT INTO语句。

SELECTINTO 语句会导致表锁定，阻止其他用户访问该表。

上面我们提到的是一些基本的提高查询速度的注意事项,但是在更多的情况下,往往需要反复试验比较不同的语句以得到最佳方案。最好的方法当然是测试，看实现相同功能的SQL语句哪个执行时间最少，但是数据库中如果数据量很少，是比较不出来的，这时可以用查看执行计划，即：把实现相同功能的多条SQL语句考到查询分析器，按CTRL+L看查所利用的索引，表扫描次数（这两个对性能影响最大），总体上看询成本百分比即可。

http://www.cnblogs.com/yongheng178/archive/2010/09/18/1829989.html

数据库命名规范

表1. 基本数据库对象命名

数据库对象

前缀

举例

表(Table)

无

Student

字段、列(Column)

无

Title,CustomerName

视图(View)

v或vw

vActivity,VW_Car

存储过程(Stored procedure)

pr或proc

prDelOrder

触发器(Trigger)

tr或trig

trOrder_D

索引(Index)

ix_

ix_CustomerID

主键(Primary key)

PK_

PK_Admin

外键(Foreign key)

Fk_

FK_Order_OrderType

Check约束(Check Constraint)

CH_

CK_TableColumn

Unique约束

UQ_

UQ_TableColumn

Default默认值

DF_

DF_Status

用户定义数据类型(User-defined data type)

udt

udtPhone

用户定义函数(User-defined function)

FN或Fun_

fnDueDate

(1)表格、字段的命名：

单数表名、字段名 还是 复数表名、字段名  （用单数来命名表名）?可能大家很少会考虑到给表名起单数还是复数，比如，对存储客人信息的表，我们应该起Customer，还是Customers？我主张起单数表名，下面是来自《SQL Server 2000 宝典》的一段引用：主张用复数表名的阵营认为：表是由一组记录构成的，所以应当使用复数名词来命名它。他们经常使用的理由是：客户表是客户们的集合，而集合意味着多个，因此应当称他们为Customers表。除非你只有一个客户，但这种情况你根本用不着数据库。根据笔者的非正式调查，有3/4的SQL Server开发人员支持使用单数命名。这些开发人员认为，客户表是客户的集合，而不是客户们的集合。一组行不应当也不会被成为rows set(行们的集合)，而会被称为row set(行集)。并且，通常在讨论时人们会使用单数名称来称呼表，说Customer表比说Customers表听起来更为清晰，避免无谓的表格后缀（没必要添加无所谓的后缀）。特殊情况下可以加复数，如用户表User，而User是数据库关键字，如果使用User表的时候，一般这样select * from [User]。此时最好使用Users

这两点我想大家都知道：1、表是用来存储数据信息的。2、表是行的集合。那么如果表名已经能够很好地说明其包含的数据信息，就不需要再添加体现上面两点的后缀了。

(2)多对多关系中连接表(中间表)的命名

大家知道，如果要实现两个实体间的多对多关系，需要三张表，其中一张是解析表。考虑下面这样一个多对多关系，这是一个经典的学生选课问题：一个学生可以选很多门课，一门课可以有很多学生。此时为了实现上面的关系，就需要一张解析表(这张表只存储学生ID和课程ID，而学生的信息和课程信息分别存在各自的表中)，这个表的起名，建议的写法是将两个表的表名合并(如果表名比较长可做简化)，此处如 StudentCourse。这个表中字段分别命名为StudentId、CourseID(既是此表的复合主键，同时分别为连接Student表和Course表的外键，等下到主键和外键的命名处再说)，这样就实现了学生和课程之间的多对多关系，当然，这个关系还可以加点额外的东西，比如给StudentCourse表中加AccessLevel字段，值域D{只读,完全,禁止}，就可以实现访问级别。

(3)约定俗成的字段名前/后缀

数据库开发的时间久了，慢慢就会摸索出一个规律来：就是很多的字段都有些共同的特性。比如说，有的字段是代表时间的(例如发帖时间，评论时间)，有的是代表数量的(例如浏览数，评论数)，有的是代表真假类型的(例如是否将博客随笔显示在首页)。对于这种同一类型的字段，应该使用统一的 前缀或者 后缀去标识它。

我们来举几个例子看得更明白一点。

以大家都熟悉的论坛来说，需要记录会员最后一次登录的时间，这时候一般人都会把这个字段命名为LoginTime 或者 LoginDate。这时候，已经产生了一个歧义：对于另一名开发者来说，如果仅看表的字段名称，不去看表的内容，很容易将LoginTime理解成 登录的次数，因为，Time还有一个很常用的意思，就是次数。为了避免这种情况发生，应该明确的规定：所有表示时间的字段，统一以 Date 来作为结尾。我们经常需要统计发帖数、回帖数信息，这时候，开发人员通常会这样去命名字段：PostAmount、PostTime、PostCount，同样，由于Time的歧义，我们首先排除掉不使用PostTime作为字段名。接下来，Amount 和 Count 都可以表示计数的意思，用哪个合适呢？这里，我推荐使用Count。为什么呢？如果你做过Asp开发，相信一定知道 RecordCount 这个属性，命名的时候有一个原则：就是使用约定俗成的名称，而不要去自创名称。既然微软都用Count后缀来表示数目，我们为什么不呢？

于是，所有表示数目的字段，都应该以Count作为结尾。将这一概念做以推广，很容易得出，浏览次数为 ViewCount，登录次数为LoginCount 等等。再举一个例子，我们很少在数据库里直接保存图片等二进制数据，通常是仅保存图片的URL路径；在文章管理系统中，如果是转载文章，也会用到记录文章出处的字段。个人建议所有代表链接的字段，均为Url结尾。于是，图片路径的字段命名为 ImageUrl，文章出处字段的命名为SourceUrl。

最后一个例子，我们经常需要用到布尔值，比方说，这篇随笔要不要显示到首页，这篇随笔是不是保存到草稿箱等等。同样，按照微软的建议，布尔类型的值均以 Is、Has、Exist 或者 Can开头。如果让我来建表示是否将随笔放到首页的字段，它的名字一定是这样的：IsOnIndex

(4)字段命名时需注意的一个问题

我发现有很多开发人员喜欢给字段加上表名作为它的前缀，举个例子，如果有个表叫User，那么他就会将这个表中的字段命名为：UserId、UserPassword、UserName、UserPhone　等等。个人认为，这是没有必要的，因为你已经确切的知道了这个表存储的是User的信息，那么其中的字段必然是针对于User的。而且，在Join连接操作中，你的SQL代码看上去也会更加的精简一些，诸如　[User].UserName =Aritcle.ArticleAuthor 这样的代码完全可以实现为　[User].Name = Article.Author。（没必要添加无所谓的后缀）

这里还存在一个特例，就是表的外键包含的字段。在这种情况下，我倾向于使用表名+ID　的方式，比如　CategoryId、UserId 等。假设有表Article，那么它的主键我会命名为Id，关联用户表User的外键包含的字段，我会命名为UserId。之所以这样，是因为在语言(比如C#)中创建对象时，有时候会使用代码生成器(根据数据库的字段名生成对象的字段、属性名)，此时生成的代码更规整一些。（对于外键要用到，外表名+Id）

(5)外键的命名

外键的命名为 fk_外键所在的表名_外键引用的表名。因为外键所在的表为从表，所以上式可以写为 fk_从表名_主表名。外键包含的字段的命名，外键包含的字段和外键是完全不同的概念。外键包含字段的命名，建议为：外键所在的表名 + Id。考虑这样一个关系，表Hotel，字段Id, Name, CityId。表City,字段Id,Name。因为一个城市可能有好多家酒店，所以是一个一对多的关系，City是主表(1方)，Hotel是从表(多方)。在Hotel表中，CityId是做为外键使用。在实现外键的时候我们可以这样写：

Alter Table HotelInfo

Add Constraint fk_HotelInfo_City ForeignKey (CityID) References City(ID)

On Delete No Action On update No Action

很明显，fk_HotelInfo_City是外键的名字，CityId是外键包含的字段的名字。

在创建数据库表的时候，一般需要写成三个SQL脚本文件。第一个文件仅包含所有的创建表的SQL语句，即CreateTable 语句。第二个文件包含删除关系和表的语句，其中，所有删除关系的语句，即Drop Constraint 语句集中在这个文件的上半部分，所有删除表的语句，Drop Table语句，集中在这个文件的下半部分。第三个文件包含建立表之间关系的语句。这种做法会在你移植数据库的时候产生较大的便利，原因我就不解释了，您一试便知。而对于多对多关系中解析表的外键包含的字段，顺理往下推，我们可以这样写(再次回到学生选课的多对多例子中)：

建立解析表StudentCourse与Student表的外键关系：

Alter Table StudentCourse

Add Constraint fk_StudentCourse_StudentForeign Key (StudentId) References Student (Id)

On Delete No Action On Update No Action

建立解析表StudentCourse与Course 表的外键关系:

Alter Table StudentCourse

Add Constraint fk_StudentCourse_CourseForeign Key (CourseId) References Course(Id)

On Delete No Action On Update No Action

(6)以Not Null的思路建表

我发现很多开发人员在建表的时候，如果要新建一个字段，他的思路是这样的：默认这个字段是可以为Null的，然后去判断是不是非要NotNull不可，如果不是这样，OK，这个字段可以为Null，接着继续进行下一个字段。结果往往是一张表除了主键以外所有的字段都可以为Null。之所以会有这样的思路，是因为Null好啊，程序不容易出错啊，你插入记录的时候如果不小心忘输了一个字段，程序依然可以Run，而不会出现 “XX字段不能为Null”的错误消息。但是，这样做的结果却是很严重的，也会使你的程序变得更加繁琐，你不得不进行一些无谓的空值处理，以避免程序出错。更糟的是，如果一些重要数据，比如说订单的某一项值为Null了，那么大家知道，任何值与Null相操作(比如加减乘除)，结果都是Null，导致的结果就是订单的总金额也为Null。

你可以运行下面的代码尝试一下：

Select Null + 5 As Result

你可能会说，就算我将字段设置成Not Null，但是它依然可以接受空字符串，这样一来在程序中还是要进行空值处理。请别忘了，数据库还赋予你一个强力武器，就是 Check 约束，当你需要确保一个字段既不可以为Null，又不可以为空的时候，可以这么写：

ColumnName    Varchar(50)       Not Null Constraint ck_ColumnNameCheck(Len(ColumnName) > 0)

所以，合理的思维方式应该是这样的：默认这个字段是 Not Null的，然后判断这个字段是不是非为Null不可，如果不是这样，OK，这个字段是Not Null的，进行下一个字段。

一个建表的范例脚本个建表的范例脚本

我正在建立我自己的个人空间，其中的文章表是这样写的：

Create Table Article

(

Id           Int Identity(1,1) Not Null,

Title         Varchar(50)       Not Null Constraint uq_ArticleTitleUnique,

Keywords      Varchar(50)       Not Null,

Abstract      Varchar(500)      Not Null,

Author        Varchar(50)       Not Null Default '张三',

Type          TinyInt           Not Null Default 0 Constraintck_ArticleType Check(Type in (0,1,2)), -- 0,原创；1,编译；2,翻译

IsOnIndex     Bit               Not Null Default 1,   -- 是否显示在首页

Content       Text              Not Null,

SourceCode    Varchar(100)      Null, -- 程序源码的下载路径

Source        Varchar(50)       Not Null Default 'TraceFact',   -- 文章出处

SrcUrl        Varchar(150)      Null, -- 文章出处的URL

PostDate      DateTime          Not Null Default GetDate(),

ViewCount     Int               Not Null Default 0,

ClassId       Int               Not Null   -- 外键包含的字段，文章类别

Constraint pk_Article Primary Key(Id)  -- 建立主键

)

可以看到，在这里我使用了Check 约束，以确保文章类型只能为0,1,2。这里，我想说的是Check约束的命名规则：尽管Check约束是针对字段的，但在同一数据库中，却不能有同名的Check约束。所以，建议使用 ck_ + 表名 + 字段名来命名它，比如这个范例脚本中的 ck_ArticleType。除此以外，我还使用了Unique约束，以确保文章标题的唯一性。由于这是我的博客文章表，不应该出现重复的题目，这样可以避免在使用 Insert 语句时插入重复值。类似于Check约束，这里的命名规则是：uq_+ 表名 + 字段名。

(7)触发器的命名

由三部分构成：

前缀(tr),描述了数据库对象的类型。

基本部分，描述触发器所加的表。

后缀(_I、_U、_D)，显示了修改语句(Insert,Update及Delete)

(8)存储过程的命名

大家知道，系统存储过程的前缀是 sp_，为了避免将用户存储过程与系统存储过程混淆，这里我推荐大家使用 pr 作为自己定义的存储过程的命名。

同时，命名的规则是：采用自解释型的命名，比如：prGetItemById。

这里，有个有意思的地方值得深思。我们按上面规则命名存储过程的时候，可以用两种方式：

动词放前面，名词放后面。

名词放前面，动词放后面。

我个人推荐使用方式2，现在说说原因：

以NorthWind 为例，假如对于 Employees 表你有4个存储过程，分别命名为：prEmployeeInsert、prEmployeeUpdate、prEmployeeDelById、prEmployeeGetById

同时对于 Products 表你有类似的4个存储过程，分别命名为：prProductInsert、prProductUpdate、prProductDelById、prProductGetById

这时，你用企业管理器查看时，会发现存储过程像下面这样整整齐齐的排列：

prEmployeeDelById

prEmployeeGetById

prEmployeeInsert

prEmployeeUpdate

prProductDelById

prProductGetById

prProductInsert

prProductUpdate

很容易就会发现，当你的存储过程越多时，这种命名方法的优势就越明显。

(9)存储过程中参数的命名

存储过程中的入口参数，我建议与其对应的字段名相同，这里，假设要写一个更新Northwind数据库Employees表的存储过程(做了简化)，可以这么写：

Create Procedure prEmployeeUpdateById

@EmployeeId       Int,

@LastName     NVarchar(20),

@FirstName    NVarchar(10)

As

Update Employees Set

LastName = @LastName,

FirstName = @FirstName

Where

EmployeeId = @EmployeeId

If @@error <> 0 or @@RowCount = 0

Raiserror 16001 ‘更新用户失败’

总结：

（Id统一这样命名不进行ID获取id这样的命名）

1.数据库表的命名：用头个字母大写的方式进行命名，对于有多个单词组成的在适当看具体情况进行裁剪。

2.对于字段命名，采取和表命名一样的规则，个人习惯的命名规则是：表名+字段名。（自己觉得可以允许这样适当的冗余）

3.外键命名：外表名+Id

4.对于存储过程的命名遵循上面所说的原则，pr+名词（通常指表名）+动词操作。

5.对于存储过程中参数的命名：和该存储过程所作用的数据表的相关字段一样也就是在其前面加一个@。对于存储过程中相应临时参数的命名也是一样的，用头个字母大写的方式进行命名。

6.对于触发器的命名：用tr前缀：tr+所作用的表名+After/Before（I/D/U） trProductAfterI