数据库建表原则，SQL数据库建表前期优化，SQL数据库操做优化，数据库命名规范

关键字: 数据库建表原则

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

能够是一对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数据库建表前期优化

关于数据库优化方面的文章不少，可是有的写的似是而非，有的不切实际，对一个数据库来讲，只能作到更优，不可能最优，而且因为实际需求不一样，优化方案仍是有所差别，根据实际须要关心的方面（速度、存储空间、可维护性、可拓展性）来优化数据库，而这些方面每每又是相互矛盾的，下面结合网上的一些见解和本身的一些观点作个总结。

　　一个系统的性能的提升，不仅仅是试运行或者维护阶段的性能调优，也不仅仅是开发阶段的事情，而是在整个软件生命周期都须要注意。因此我但愿按照软件生命周期的不一样阶段来总结数据库性能优化相关的注意事项。

 

　　1、 分析阶段

 

　　通常来讲，在系统分析阶段每每有太多须要关注的地方，系统各类功能性、可用性、可靠性、安全性需求每每吸引了咱们大部分的注意力，可是，咱们必须注意，性能是很重要的非功能性需求，必须根据系统的特色肯定其实时性需求、响应时间的需求、硬件的配置等。最好能有各类需求的量化的指标。

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

 

　　2、 设计阶段

 

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

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

　　如下是性能要求设计阶段须要注意的：

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

　　数据库逻辑设计的规范化就是咱们通常所说的范式，咱们能够这样来简单理解范式：

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

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

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

　　更高的范式要求这里就再也不做介绍了，我的认为，若是所有达到第二范式，大部分达到第三范式，系统会产生较少的列和较多的表，于是减小了数据冗余，也利于性能的提升。

　　二、合理的冗余

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

　　冗余能够是冗余数据库、冗余表或者冗余字段，不一样粒度的冗余能够起到不一样的做用。

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

　　三、主键的设计

　　主键是必要的，SQLSERVER的主键同时是一个惟一索引，并且在实际应用中，咱们每每选择最小的键组合做为主键，因此主键每每适合做为表的汇集索引。汇集索引对查询的影响是比较大的，这个在下面索引的叙述。

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

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

　　四、外键的设计

外键做为数据库对象，不少人认为麻烦而不用，实际上，外键在大部分状况下是颇有用的，理由是：

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

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

　　五、字段的设计

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

　　A、数据类型尽可能用数字型，数字型的比较比字符型的快不少。

　　B、数据类型尽可能小，这里的尽可能小是指在知足能够预见的将来需求的前提下的。

　　C、尽可能不要容许NULL，除非必要，能够用NOT NULL+DEFAULT代替。

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

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

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

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

　　这里须要注意文件组的做用，适用文件组能够有效把I/O操做分散到不一样的物理硬盘，提升并发能力。

　　七、系统设计

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

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

　　八、索引的设计

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

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

　　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

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

2二、使用视图加速查询

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

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，因此查询工做量能够获得大幅减小。

2三、能用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

这两点我想你们都知道：一、表是用来存储数据信息的。二、表是行的集合。那么若是表名已经可以很好地说明其包含的数据信息，就不须要再添加体现上面两点的后缀了。

(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