SQL Server 数据库设计规范

数据库设计规范

1.简介

数据库设计是指对一个给定的应用环境，构造最优的数据库模式，创建数据库及其余应用系统，使之能有效地存储数据，知足各类用户的需求。数据库设计过程当中命名规范非常重要，命名规范合理的设计可以省去开发人员不少时间去区别数据库实体。

最近也由于工做须要因此整理出了这个word文档，望你们指正。

 

2数据库设计

数据库规划→需求分析→数据库设计→应用程序设计→实现→测试→运行于维护

2.1数据库规划

定义数据库应用系统的主要目标，定义系统特定任务，包括工做量的估计、使用资源、和需求经费，定义系统的范围以及边界。

2.2需求分析

2.1.1需求分析步骤与成果

涉及人员：用户和分析人员

任务：对现实世界要处理的对象进行详细的调查，收集基础数据及处理方法，在用户调查的基础上经过分析，逐步明确用户对系统的需求，包括信息的要求及处理的要求。

方法与步骤：1.经过与用户的调查，对用户的信息需求进行收集。

2.在收集数据的同时，设计人员要对其进行加工和整理，以数据字典和数据流图的形式描述出来，并以设计人员的角度向用户讲述信息，根据用户的反馈加以修改并肯定（该过程是反复的过程）

成果：数据流图，数据字典，各类说明性表格，统计输出表以及系统功能结构图。

2.1.2数据流图基本元素与数据流图

外部实体：存在于软件系统以外的人员或组织（正方形或立方体表示）。

加工：数据处理，表示输入数据在此进行变换，产生输出数据（圆角巨型或圆形表示）。

数据流：表示流动着的数据（箭头线表示）。

数据存储：用来表示要存储的数据（开门矩形或两条平行横线表示）。

 

 

 

订单处理系统顶层流程图：

0层数据流图：

                                    

 

 

2.3数据库设计

2.3.1概念结构设计

• 对事务加以抽象以E-R图的形式描述出来
• E-R图（实体联系图）：包括实体，联系，属性

实体：现实中的事物例如，学生，老师

联系：两个实体之间的关系，1:一、1：N、M:N三种关系

属性：实体所具备的属性，例如 学生的学号、姓名、性别等

例如：一个学生属于一个班级，一个班级拥有多名学生，E-R图以下

 

 

 

网上购物系统E-R图，该系统数据之间存在下列约束

 

1. 一个客户（编号惟一）能够拥有多个订单，每一个订单仅属于一个客户。
2. 一个订单（编号惟一）能够包含多个订购细目，每一个订购细目只属于一个订单。
3. 一个商品能够出现多个订购细目中，一个订购细目只包含多个商品。
4. 一个商品类别能够包含多种商品，一种商品只属于一个商品类别。

 

 
 

 

图2.2

2.3.2逻辑结构设计

2.3.2.1E-R图转换成关系模式

•  将E-R图转换成关系模式

将每一个实体转换成一个关系模式，实体的属性即关系模式的属性，实体的标识即关系模式的键。

•  根据规则合并E-R图中的1:1,1:N,M:N之间的联系

1. 若实体的联系是(1:1)，则能够将两个实体转换成两个关系模式，任意一个关系模式的属性中加入另外一个关系模式的主键（做为外键）和联系自身的属性
2. 若实体间的联系是一对多（1：n），则将n端的实体类型转换成关系模式中加入1端实体类型的主键（做为外键）和联系类型的属性。
3. 若实体间的联系是多对多（m:n），则将联系类型也转换成关系模式，其属性为2实体类型的主键（做为外键）加上联系类型自身的属性，而该关系模式的主键为2端实体主键的组合。
4. 若关系模式是1：1：1的关系，转换原则同1：1
5. 若关系模式是1：1：n的联系，转换原则同1：n
6. 若关系模式是1：n：m的联系，则能够将联系类型也转换成关系模式，其属性为m端和n端实体类型的主键（做为外键）加上联系类型自身的属性，而关系模式的主键为n和m端实体主键的组合
7. 若关系模式是n:m:p的联系，转换规则同m:n

根据E-R图实体之间的联系能够转换成如下关系模式：

客户（客户编号，姓名，电话，E-mail）。关系的主键：客户编号；外键：无

订单（订单编号，订购时间，客户编号）。关系的主键：订单编号；外键：客户编号

订购细目（订购明细编号，订购数量，支付金额，订单编号）。关系主键：订购明细编号；外键：订单编号。

出现（订购明细编号，商品编号，类型）。关系的主键：订购明细编号，商品编号；外键：订购明细编号，商品编号。

商品：（商品编号，商品名称，单价，生产日期，商品类别号，商品类别名）。关系的主键：商品编号；外键：无

在关系模式设计中可能会出现如下几个问题：数据冗余、数据修改不一致、数据插入异常、数据删除异常，因此提出范式的要求，目的就是最低限度地冗余，避免插入、删除、修改异常。

2.3.2.2范式

主属性：包含键的全部属性。

•  关系模式要求达到4NF （减小冗余，消除操做异常）

第一范式（1NF）：若关系模式R的每个份量是不可分的数据项，则关系模式属于第一范式。即每一个属性都是不可拆分的.

第二范式(2NF)：R属于1NF,且每个非主属性彻底依赖于键（没有部分依赖），则R属于2NF

例如：选课关系(学号，课程号，成绩，学分)

该关系的主键是（学号，课程号），可是课程号→学分，因此学分属性部分依赖于主键，即关系部知足第二范式，能够拆分为（学号，课程号，成绩），（课程号，学分）两个关系

第三范式(3NF)：R属于2NF,且每一个非主属性即不部分依赖于码，也不传递依赖于码

例如：学生关系（学号，姓名，所属系，系地址）

该关系的主键是:学号

学号→所属系，所属系→学号，所属系→系地址；根据函数的依赖公理，系地址传递函数依赖于学号，即关系不知足第三范式，能够拆分关系为（学号，姓名，所属系），（所属系，系地址）

若是不拆分会存在数据修改异常，好比该学生的换了系，修改了所属系，可是系地址没有修改，这样就形成了修改异常

 BCNF：R属于3NF,且不存在主属性对码的部分和传递函数依赖

例如：关系R（零件号，零件名，厂商名），若是设定每种零件号只有一个零件名，但不一样的的零件号能够有相同的零件名，每种零件能够有多个厂商生产，但每家厂商生产的零件应有不一样的零件名。这样能够获得：

零件号→零件名，（厂商名，零件名）→零件号

因此主属性包括（零件号，厂商名，零件名），可是“零件名”传递依赖于码“厂商名，零件名”，因此关系R不知足BCNF，当一个零件由多个生产厂商生产时，因为零件号只有一个而零件名根据厂商不一样而又多个，零件名与零件号之间的联系将屡次重复，带来数据冗余和操做异常现象

能够将关系分解为（零件号，厂商名），（零件号，零件名）

4NF：关系模式R属于1NF,若对于R的每一个非平凡多值依赖X→→Y且Y不包含于X时，X必含码，则R属于4NF

5NF:对关系进行投影，消除关系中不是由候选码所蕴含的链接依赖

对于上面的商品关系，因为关系的主键是商品编号，而商品类别号→商品类别名

因此商品关系部知足第三范式，非主属性商品类别名传递依赖于商品编号，会存在数据冗余，数据修改异常问题。将商品关系分解为：

商品（商品编号，商品名称，单价，生产日期，商品类别号）

商品类别（商品类别号，商品类别名）

2.3.3物理结构设计

为一个给定的逻辑数据模型设计一个最合适应用要求的物理结构的过程

•  数据库的创建
•  数据表的创建
•  索引的创建
•  视图的创建
•  触发器的创建
•  存储过程设计
• 用户自定义函数设计
•  对关系模式的数据项加以约束，如检查约束、主键约束、参照完整性约束以保证数据正确性

 

2.4应用程序设计

采用高级语言以结构化设计方法或面向对象方法进行设计

2.5系统实现

 

3.优化策略

3.1.查询优化策略

1. 尽量地减小多表查询或创建物化视图
2. 只检索须要的列
3. 用带IN的条件字句等级替换or字句
4. 关联查询替代相关子查询
5. 单个事务不宜太长，以尽早释放锁

 

3.2表设计

1.若是频繁地访问涉及的是对两个相关的表进行链接操做，则考虑将其合并

2.若是频繁地访问只是在表中的某一部分字段上进行，则考虑分解表，将该部分单独做为一个表

3.对于不多更新的表，引入物化视图

4. 当系统中有一些少许的，重复出现的值时，使用字典表来节约存储空间和优化查询。如地区、系统中用户类型的代号等。这类值不会在程序的运行期变化，可是须要存储在数据库中。

   就地区而言，若是咱们要查询某个地区的记录，则数据库须要经过字符串匹配的方式来查询；若是将地区改成一个地区的代号保存在表中，查询时经过地区的代号来查询，则查询的效率将大大提升。

程序中宜大量的使用字典表来表示这类值。字典表中保存这类值的代号和实体的集合，之外键的方式关联到使用这类值的表中。然而，在编码阶段，程序员并不使用字典表，由于首先查询字典表中实体的代号，违背了提升查询效率的初衷。程序员在数据字典的帮助下，直接使用代号来表明实体，从而提升效率。

虽然字典表在实际上并不使用，可是仍应该保留在数据库中（起码是在开发期内保留）。字典表做为另外一种形式上的“数据字典文档”出现，以说明数据库中哪些表的哪些字段是使用了字典表的。

为了提升数据库的数据完整性，在开发阶段能够保留完整的字典表和普通表的外键约束。可是在数据库的运行阶段，应该将普通表和字典表的外键删除，以提升运行效率，特别是某些表使用了不少字典表的状况。

 

   案例：某数据库中有百万条用户信息，应用系统中经常须要按照地区要查询用户的信息。用户信息表之前是按照具体的地区名称来保存的，如今将具体的名称改成字典表中的地区代号，查询效率大大提升。

 

3.3索引

1. 若是查询是瓶颈，则在关系上创建适当的索引；一般，做为查询条件的属性上创建索引能够提升查询效率。
2. 若是更新是瓶颈，由于每次更新都会重建表上的索引，引发效率下降，则考虑删除某些索引。
3. 选择适当索引，若是常用范围查询，则B树索引比散列索引更高效
4. 将有利于大多数查询和更新的索引设为汇集性索引。

 

3.4提升IO效率

1. 索引文件和数据文件分开存储，事务日志文件存储在高速设备上
2. 常常修改数据文件和索引文件的页面大小
3. 按期对数据进行排序
4. 增长必要的索引项

4.数据库命名规范

4.1数据库对象

对象	前缀
数据库	无
表	无
视图	VW
索引	IX
存储过程	SP\SPChange
函数	FN
触发器	TR
自定义数据类型	UD
Default	DF
主键	PK
外键	FK
rule	RU
序列	SQ
UNIQUE	UQ

数据库对象采用26个英文字母（区分大小写）和0－9这十个天然数，加上下划线_组成，共63个字符。不能出现其余字符（注释除外）。

同一个数据库中这些对象名都是不能重复

C    CHECK_CONSTRAINT

D    DEFAULT_CONSTRAINT

F    FOREIGN_KEY_CONSTRAINT

IT   INTERNAL_TABLE

P    SQL_STORED_PROCEDURE

PK   PRIMARY_KEY_CONSTRAINT

S    SYSTEM_TABLE

SQ   SERVICE_QUEUE

TR   SQL_TRIGGER

U    USER_TABLE

UQ   UNIQUE_CONSTRAINT

V    VIEW

4.2命名规范规定

1.表名使用单数名

例如：对存储客人信息的表（Customer）不使用Customers

2.避免无谓的表格后缀

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

二、  GuestInfo(存储客户信息)应写成Guest，FlightList（存储航班信息的表）应写成Flight

3.全部表示时间的字段，统一以 Date 来做为结尾（而不是有的使用Date,有的使用Time）

以你们都熟悉的论坛来讲，须要记录会员最后一次登陆的时间，这时候通常人都会把这个字段命名为LoginTime 或者 LoginDate。这时候，已经产生了一个歧义;若是仅看表的字段名称，不去看表的内容，很容易将LoginTime理解成登陆的次数，由于，Time还有一个很经常使用的意思，就是次数

4.全部表示数目的字段，都应该以Count做为结尾

5.全部表明连接的字段，均为Url结尾

6.全部名称的字符范围为：A-Z, a-z, 0-9 和_(下划线)。不容许使用其余字符做为名称。

7.采用英文单词或英文短语（包括缩写）做为名称，不能使用无心义的字符或汉语拼音。

8.名称应该清晰明了，可以准确表达事物的含义，最好可读，遵循“见名知意”的原则。

 

4.3数据库命名规范

数据库名称不须要简写，根据实际意义来命名。例如：ReportServer

数据库名：ReportServer

逻辑数据名：ReportServer；逻辑日志名：ReportServer_log

物理数据名：ReportServer.mdf；物理日志名：ReportServer_log.LDF

CREATE DATABASE [ReportServer] ON  PRIMARY

( NAME = N'ReportServer', FILENAME = N'D:\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\useData\ReportServer.mdf' , SIZE = 3328KB , MAXSIZE = UNLIMITED, FILEGROWTH = 1024KB )

 LOG ON

( NAME = N'ReportServer_log', FILENAME = N'D:\Microsoft SQL Server\MSSQL10.MSSQLSERVER\MSSQL\useData\ReportServer_log.LDF' , SIZE = 6400KB , MAXSIZE = 2048GB , FILEGROWTH = 10%)

GO

注意：避免全部数据库的逻辑名称使用相同的名称。

4.4表设计命名规范

注意字段名不能使用保留关键字：如action,avg等

一、不使用tab或tbl做为表前缀（原本就是一个表，为何还要说明）

二、表名以表明表内的内容的一个和多个名词组成，如下划线分隔，每一个名词的第一个字母大写，例如：User、UserLogin，UserGroupRelation等

三、使用表的内容分类做为表名的前缀：如，与用户信息相关的表使用前缀User，与内容相关的信息使用前缀Content。

四、表的前缀之后，是表的具体内容的描述。如：用户登陆信息的表名为：UserLogin，用户在论坛中的信息的表名为：UserBBSInfo

五、一些做为多对多链接的表，可使用两个表的前缀做为表名：

         如：用户登陆表UserLogin，用户分组表GroupInfo，这两个表创建多对多关系的表名为：UserGroupRelation

4.4.1字段命名规范

1. 字段名不要存在无用前缀，例如表‘WeiXinConfig’，既然我已经知道这张表是关于微信的表，里面的名称字段能够可使用Name,不须要添加无用的前缀相似‘WeiXinName’，‘WeiXinGuanZhuMsg’，‘WeiXinUpImgMsg’等
2. 字段使用实际英文翻译做为命名字段，见名知意,不要使用让人看了半天都不知道是啥意思的字段（相似：lev1,lev2…）

4.5存储过程命名

存储过程名=[SP]+[查询修改标示]+[表名]

例如：

查询存储过程

SPCommunity

修改存储过程

SPChangeCommunity

4.5.1只容许应用程序经过存储过程访问数据库

   只容许应用程序经过存储过程访问数据库，而不容许直接在代码中写SQL语句访问数据库。

在数据库开发项目中，大量使用存储过程有不少的好处，首先看微软提供信息：

使用 SQL Server 中的存储过程而不使用存储在客户计算机本地的 Transact-SQL 程序的优点有： 容许模块化程序设计： 只需建立过程一次并将其存储在数据库中，之后便可在程序中调用该过程任意次。存储过程可由在数据库编程方面有专长的人员建立，并可独立于程序源代码而单独修改。 容许更快执行： 若是某操做须要大量 Transact-SQL 代码或需重复执行，存储过程将比 Transact-SQL 批代码的执行要快。将在建立存储过程时对其进行分析和优化，并可在首次执行该过程后使用该过程的内存中版本。每次运行 Transact-SQL 语句时，都要从客户端重复发送，而且在 SQL Server 每次执行这些语句时，都要对其进行编译和优化。 减小网络流量： 一个须要数百行 Transact-SQL 代码的操做由一条执行过程代码的单独语句就可实现，而不须要在网络中发送数百行代码。 可做为安全机制使用： 即便对于没有直接执行存储过程当中语句的权限的用户，也可授予他们执行该存储过程的权限。

 

   除此之外，使用存储过程的好处还有：

一、  在逻辑上，存储过程将应用程序层和数据库物理结构分离开来。存储过程造成了一个应用程序和数据库之间的接口。这样的接口抽象了复杂的数据库结构，符合极限编程中“基于接口编程”的思想。

二、  将主要的业务逻辑封装在存储过程当中，可以避免在应用程序层写大量的代码（在应用程序中经过字符串插入太长的SQL语句影响效率，并且维护困难）。有助于提升开发效率，而且直接在查询分析器中调试存储过程，可以更早的发现系统中的逻辑问题，从而提升代码的质量。

三、  在网站一类的应用系统中，SQL注入式漏洞一直是难以彻底杜绝的漏洞。若是只经过存储过程来访问数据库，可以大大减小这类安全性问题。（所以，就算是简单的只有一句的SQL语句，也应该写成存储过程。）

四、  因为采用存储过程，应用程序的层面能够不关心具体的数据库结构，而只关心存储过程的接口调用。所以，在如下一些状况，存储过程的优点很是明显：

·需求变动，表的结构必需要改变。使用存储过程，只要参数不变，咱们就只须要修改相应的存储过程，而不须要修改应用程序的代码。这样的设计将减少需求变动对项目的影响。

·为提升效率，使部分字段冗余：一些常常性访问的字段，咱们能够在相关的表中进行冗余存储。这样既提升了效率，又经过存储过程屏蔽了冗余细节。

·为提升效率，使用冗余表（拆分表）：一些大的表，为了提升查询效率，可能须要将记录分别保存到多个表中去。使用存储过程，有存储过程来决定从哪些拆分的表中获取或插入数据。这样提升了效率，又没必要在应用程序层面关心具体的拆分规则。

五、 使用存储过程，便于在项目后期或者运行中集中优化系统性能。在项目开发过程当中，因为各类缘由，每每没法编写高效的代码，这个问题经常在项目后期或者在运行期体现出来。经过存储过程来封装对数据库的访问，能够在项目集成之后，经过试运行观察系统的运行效率，从而很容易找出系统的瓶颈，并可以经过优化存储过程的代码来提升系统的运行效率。这样的优化，比在运用程序中优化更有效，更容易。

 

同时，过多的使用存储过程，也存在如下一些疑虑：

问题一：存储过程编译后，将做为数据库的全局对象保存，太多的存储过程将占用大量的数据库服务器的内存。

问题二：在存储过程当中实现大量的逻辑，将使大量的运算在数据库服务器上完成，而不是在应用服务器上完成。当访问量很大的时候，会大大消耗数据库服务器的CPU占用率。

在此还存在这个一个案例：有一个访问量巨大的网站，有多台WEB服务器构成一个负载均衡的服务器群集，可是只有一台中心的数据库服务器。当访问量持续增长的时候，接入更多的WEB服务器来知足高并发量的访问；可是数据库服务器却没办法一直增长。所以，就须要尽可能在WEB服务器上完成业务逻辑，尽可能避免消耗数据库服务器的资源。

 

   对于这两个担忧，个人想法是：

问题一的解决：存储过程是通过编译后的SQL语句，在内存中是二进制的代码，并不会消耗太多内存。而且，存储过程比起直接使用SQL语句来讲，效率大大提升。换个角度来讲，这是一个“以空间换时间”的方案，多消耗一点内存来换取效率的提升，是值得的。

问题二的解决：首先，在实现业务逻辑的问题上，在存储过程当中实现比在应用程序中实现更容易；其次，从开发效率上，存储过程的开发比应用程序更简单（就完成相同逻辑而言）。在高访问量的系统中，应用服务器和数据库服务器的资源分配的问题，应该从成本的角度来开率：软件开发中的成本，人工支出的费用远远高于硬件支出的成本。咱们能够很容易花钱购买更好的服务器，可是很难花钱让开发人员使程序有大幅度的提升。

使用存储过程来封装业务逻辑，首先节省的是大量的开发时间和调试时间，并可以大大提升代码的质量。所以，从成原本说，应该使用存储过程。

对于大访问量的状况，最简单的办法是投入更多的硬件成本：更快的硬盘，更大的内存和更多的CPU，还有更好的网卡…………等等。

其次，在应用程序的层面，能够大量的使用静态文件缓存的办法来减轻数据库的压力。如：不常常变化的信息，能够从数据库服务器中读取，保存为应用服务器上的XML静态文件等。

实在不行的话，应该在系统设计之初，考虑可能的访问量，将系统设计成分布式的。这样就能从根本上解决大访问量的问题。

 

4.5.2命名规范

一、存储过程的前缀和表名的前缀相似：把一系列表当作一个对象，字段为对象的属性，存储过程则为访问对象的方法。如：添加用户的存储过程取名为：User_AddUser

二、存储过程使用模块的前缀来命名。如，用户管理的存储过程使用前缀user_。

三、存储过程的前缀以后，是动词+名词形式的存储过程名（也能够是动词短语）。

4.5.3存储过程的参数命名

一、参数名采用匈牙利命名法，使用类型的前缀

二、每一个存储过程都有：@errno int和@errmsg varchar(255)两个输出参数。应用程序中能够根据这两个参数获得存储过程执行的状况。(这两个参数使用默认值，能够忽略)

errno为整型的错误信息代码，执行成功返回0。Errno的值的具体含义经过errmsg参数说明，或者经过代码中的注释或文档。

Errmsg为错误信息的字符串描述，这个参数主要用于调试期做为说明，避免在应用程序中使用该值。同时，要注意英文版系统和中文版系统中，信息的语言选择对程序的影响。

4.5.4存储过程返回的记录集

一、存储过程的输出记录集：为程序的结构清晰，存储过程最好只返回一个记录集。但在某些为了提升性能的场合，仍是能够输出多个记录集

二、记录集中，每一个输出的字段最后都指定字段的别名，以面真实的字段名信息流失到客户端，从而加大黑客找到系统漏洞的可能。

 

4.5.5格式约定

一、  全部SQL关键字大写

二、  使用良好的变量命名规范

三、  保持良好的结构，包括空行、缩进和空格等。

四、  块状的语句，必定要写上BEGIN…END

五、  在每一个存储过程的开头加上详细的注释：包括存储过程名称、参数说明、功能说明、返回数据集说明、以及做者和版权声明。

六、  每一个存储过程内的代码先后必须加上SET NOCOUNT ON 和SET NOCOUNT OFF。

七、  存储过程格式的示例以下：

CREATE PROCEDURE Pro_Alter_User

(

         @Options VarChar(100),

         @strUserName varchar(20),

         @strPwd varchar(50),

         @errno int = 0 OUTPUT,

         @errmsg varchar(255)=NULL OUTPUT

)

 

AS

BEGIN

  IF @Options='UP1'

         BEGIN

         SET NOCOUNT ON

         /*如下是存储过程的代码*/

         SET NOCOUNT OFF

         END

         

 IF @Options='UP2'

         BEGIN

         SET NOCOUNT ON

         /*如下是存储过程的代码*/

         SET NOCOUNT OFF

         END

END

 

 

4.6视图命名

一个数据库中的视图名不能重复

视图名=VW(前缀)+[表名]..[表名]+[描述]

4.7主键命名

一个数据库中的主键名不能重复

主键名=PK_(前缀)+[表名]

例如：PK_Community

 

4.8外键命名

一个数据库中的外键名不能重复

外键名=FK_(前缀)+[主表名]+[从表名]+[字段名]

考虑这样一个关系，表Hotel，字段Id, Name, CityId。表City,字段Id,Name。由于一个城市可能有好多家酒店，因此是一个一对多的关系，City是主表(1方)，Hotel是从表(多方)。在Hotel表中，CityId是作为外键使用。

在实现外键的时候咱们能够这样写：

ALTER TABLE HotelInfo
ADD CONSTRAINT FK_Hotel_City_Cityid  FOREIGN KEY (CityID) REFERENCES City(ID)

4.9触发器命名

1. 前缀(tr),描述了数据库对象的类型。
2. 基本部分，描述触发器所加的表。
3. 后缀(_I、_U、_D)，显示了修改语句(Insert, Update及Delete)

触发器名=TR_(前缀)+[表名]+[ _I、_U、_D]+[字段\描述]

例如：TR _Communtiy_u_name(对表community的字段name进行更新)

 

4.10 default约束

  使用格式如：DF_[表名]_[列名]

例如：DF _Community_Age
 

4.11 check约束

格式：CK_[表名]_[列名]

例如：CK_Community_Number

4.12 unique约束

格式：UQ_[表名]_[列名]

例如：UQ_Community_Name

 

4.13字段命名规范

一、字段不使用任何前缀（表名表明了一个名称空间，字段前面再加前缀显得罗嗦）

二、字典名也避免采用过于广泛过于简单的名称：例如，用户表中，用户名的字段为UserName比Name更好。

三、布尔型的字段，以一些助动词开头，更加直接生动：如，用户是否有留言HasMessage，用户是否经过检查IsChecked等。

四、字段名为英文短语、形容词+名词或助动词+动词时态的形式表示，大小写混合，遵循“见名知意”的原则。

4.14 SQL语句规范

一、不容许写SELECT * FROM ……，必须指明须要读取的具体字段。

二、不容许在应用程序代码中直接写SQL语句访问数据库。

三、避免在一行内写太长的SQL语句，在SQL关键字的地方将SQL语句分红多行会更加清晰。

  如：SELECT UserID,UserName,UserPwd FROM User_Login WHERE AreaID=20

修改为：

SELECT UserID,UserName,UserPwd

FROM User_Login

WHERE AreaID=20

更加直观

四、在一些块形式的SQL语句中，就算只有一行代码，也要加上BEGIN…END块。

   如：IF EXISTS(…)

                            SET @nVar = 100

应该写成：

IF EXISTS(…)

BEGIN

           SET @nVar = 100

END

五、SQL批处理语句的空行和缩进与通常的结构化程序语言一致，应该保持良好的代码格式。

六、全部的SQL关键字大写

 

4.15游标使用约定

一、  若无必要，不要使用游标

二、  包含游标的存储过程，必须对性能进行认真测试。

 

4.16索引命名规范

对于数据库的维护建索引是很日常的事情，可是若是没有一个规范化的命名，咱们对于一个表的诸多索引可能须要花上一段时间的了解。

1. 若是表中存在主键默认状况下，表的汇集性索引也就是主键列，主键的命名前面已经有提到过，索引名也跟主键名同样，（PK_表名）
2. 对于表上的非汇集索引，建议使用（IX_表名_字段简写），对于不少命名文章上提到的须要详细表达出具体的列，我我的以为没有必要，首先非汇集索引常常涉及多列，很难罗列出全部列；还有影响美观

当你执行SELECT  NAME  FROM SYS.COLUMNS 查询索引时，你根据NAME名很快就知道索引来自那张表，是不是非汇集索引，而不用根据OBJECTID列去跟对象表关联。

4.17函数命名规范

函数命名分两类：1.针对对象的函数，2.用做辅助功能操做的函数（不针对具体的数据库对象）

1. 第一类命名：FN_+[User]+_+[对象名] 例如：FN_User_Student（对于Student进行操做函数）
2. 第二类命名：FN_[具体函数解释] 例如：FN_Spit(对字段进行拆分函数)

 

 

 

备注：     做者：pursuer.chen     博客：http://www.cnblogs.com/chenmh 本站点全部随笔都是原创，欢迎你们转载；但转载时必须注明文章来源，且在文章开头明显处给明连接，不然保留追究责任的权利。 《欢迎交流讨论》