SQL Server 设计.命名编码规范

\TBL：除了下面子目录，这个目录应该包括表的定义脚本，每个表应该有它自己的脚本，此脚本应该包括经表的删除，创建语句，索引，触发器，完整性参照，Check约束，默认值约束等，每个表创建语句应该包括在不同的脚本中，并被把归类到类似于下面的相应的子目录中.注意：本目录中的脚本和以下子目录的脚本应该命名为它所影响的表名，比如：表名.sql：

\Check：为每个表创建独立的Check约束定义脚本，Check约束应该使用alter table add constraint 来创建，并且每个alter table 语句只能包括一个contraint。

\DEFAULT：为每个表创建单独的Default约束定义脚本。注意这些是Default Constraints，而不是在创建表时的Default。

\FK：为每个表创建单独的外键约束定义脚本。

\Index:为每个表创建一个索引定义脚本，并把对应索引定义脚本放进去.

\PK：为每个表创建单独的主键定义脚本

\TRG：为每个表创建单独的触发器定义脚本，并把应用到此表上的触发器放进此脚本文件中。

\UDF：用户自定义函数。

\View：视图定义脚本。

\DCL：数据控制语句脚本—主要包括控制所有的数据库对象的Grant 和 Revoke语句。

\MISC：这儿用于存放各式各样的其它脚本，例如alter table脚本或者一次更改的脚本，注意，不要放此目录看成是一个包罗各种脚本的容器，只应包括需要放到VSS中，但是又不属于上面所列目录的脚本。

4．物理数据库模型&字典

E-R 图表和数据字典可以让任何使用数据库的人都明确的知道如何从数据库中获得数据。E-R图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名

4.1 物理数据模型

物理模型图形化的展现数据库的实现，它由逻辑数据模型及底层关系型数据库管理系统来决定，由逻辑模型转变为物理模型包括以下的任务：

Ø 为实体和属性创建合理的数据库名字

Ø 为每个属性设计数据类型和是否允许为空

Ø 定义主键，外键和索引

Ø 定义规则和默认值

Ø 为优化性能，尽可能使数据库设计规范化，比如遵循1NF（第一范式），2NF（第二范式）和3NF（第三范式）

为加快数据库设计速度，目前有很多数据库辅助工具（CASE工具），如Rational公司的Rational Rose，CA公司的Erwin, Sybase公司的Power Designer以及Oracle公司的Oracle Designer等。

ERwin主要用来建立数据库的概念模型和物理模型。它能用图形化的方式，描述出实体、联系及实体的属性。ERwin支持IDEF1X方法。通过使用ERwin建模工具自动生成、更改和分析IDEF1X模型，不仅能得到优秀的业务功能和数据需求模型，而且可以实现从IDEF1X模型到数据库物理设计的转变。ERwin工具绘制的模型对应于逻辑模型和物理模型两种。在逻辑模型中，IDEF1X工具箱可以方便地用图形化的方式构建和绘制实体联系及实体的属性。在物理模型中，ERwin可以定义对应的表、列，并可针对各种数据库管理系统自动转换为适当的类型。

设计人员可根据需要选用相应的数据库设计建模工具。例如需求分析完成之后，设计人员可以使用Erwin画ER图，将ER图转换为关系数据模型，生成数据库结构；画数据流图，生成应用程序。

ERwin是现在被广泛使用的数据模型设计软件，IDEF1X用来建立信息模型的标准。物理模型基于逻辑模型,ERwin同时支持逻辑模型和物理模型视图的设计。同时，ERwin可以产生所有的用来创建数据库的DDL脚本.

4.2 IDEF1X 方法

下面的关系图描述最常用的IDEF1X表达式协定：

4.3物理数据库数据字典

使用ERwin来对物理数据库数据字典进行维护。在属性定义编辑器中输入属性定义。然后你就可以从ERwin中生成报表，把它们放到word 文档中，在属性报表中，将包括属性名字，数据类型，Null/Not Null和主/外键选项。把实体和属性定义放到一个一个文档中是很困难的，所以在不同的报表中创建它们.

4.4 性能设计

作为一个常规的规则，在一个具有标识列(identity property)的列上定义一个主键。这使与之存在关系的表有一个窄的行宽，从而使同一数据页中能被存储更多的数据行，因此相同条件下将会有更少的描描操作。

Ø 定义聚集主键，这将会使二级索引占用较少空间。

Ø 在外键上创建索引。

Ø 不要使用过多的索引，要确认你知道哪个索引将被使用。

Ø 确认对应表存在统计信息。同时在数据库中打开Auto Generate Stats 和 Auto create stats 选项。在一个只读的数据库中，我们可能需要手动的创建统计信息.

Ø 在一个只读的数据库或者是很少被更改的数据库中使用100%的索引填充率。

Ø SELECT语句中，在非事务和特别的完整性要求的上下文中，要使用Table Hints――WITH NOLOCK

5．命名协定

5.1 数据库命名原则及版本控制

5.1.1数据库命名原则

数据库命名要遵从以下命名原则：

表意性原则:数据库命名本着表意性原则，即命名应尽量反映存储/action/view/column的数据内容。

长名原则：很少使用或者不使用缩写，适用于DB命名之外的任一对象

数目最少化原则：数据库对象应该尽量满足数据最小化原则，也就是数据库数目，存储过程，视图等数量最小化。

5.1.2 数据库版本控制

当由于多个版本的应用系统同时存在或者是其它特殊原因而使用完成相似的功能的对象存在同时存在时，使用版本控制：版本号在对象名的后面加上[_v1]

如：

　　　 Up_IM_DailyUsageStatsUpdate_v2

Up_IM_CustomerGetUsingLastName_v2

5.2 Server/命名实例的命名

基于Domain命名, DOMAIN 的粒度，可分为三级 ,分别是Server级别，Database级别和表的前缀级别。此为第一级别。

1． ONLINE PRODUCTION SERVER

NEWSQL

NEWSQL2

EHISSQL

WAREHOUSE PRODUCTION SERVER

S3SQL01

S4SQL01

S7SQL01

S6SQL01

5.3 数据库命名

数据库命名应当遵从上面所提及到的协定，包括没有特殊的字符,使用文字数据字式字符……..,项目代码命名不应该同样被数据库使用.数据库名字应该唯一以避免冲突等.以Domain来标识, 拆分DATABASE，基于大的逻辑范畴，如operation 范畴以及部门类别,另外：其它与部门相关的DATABASE 可以放到相关的SERVER 下。

Ø 数据库数目最少化原则

Ø 数据设置尽可能MERGER原则

Ø peration database AND Dept level Database set up rules

Ø 拆分DATABASE，基于大的逻辑范畴，如operation 范畴以及部门类别

Ø 其它与部门相关的DATABASE 可以放到相关的SERVER 下。

Ø 下面为与OPEARATION 相关的DATABASE示例：

如: 下面为与OPEARATION 相关的DATABASE:

ItemProfile

Inventory

Codecenter

CustomerProfile

SalesOrder

Accounting

Sevice(RAM)

eCommerce

SupplerChainManagement

                     DropShip
                      SerialNumber
                      WorkFlow

ShippingCarrier

WarehouseManagment

HumanResource

Ø 其它与部门相关的DATABASE 可以放到相关的SERVER 下。

MKT

Mis

CUSTOMER SVR

ADMIN

ACCOUNTING

2. INTERNAL DEPT DATABASE SERVER

5.4数据库对象—表，视图，列名，约束，规则，默认值

数据库对象应该被清晰的命名，要确认不存在歧义。数据库对象的名字应该包括自己尽可能多的信息，并要详细的说明与之相对应的项目文档.选择合适的命名空间是一个很让人困惑的问题（比如我们不能从一个存储过程的命名上看到是哪个项目在使用这个对象），命名名字唯一的在数据库级别标识自己，无论在哪儿使用它，请确保在一个项目中命名方法的一致.在一个小的上下文看来很清晰的对象在一个大的上下文中可能就会丢失他的含义.节省击键次数永远不能用来作选择名字的标准.

下面供述了数据库对象的命名协定，所有的数据库对象命名都应该遵循下面协定.

Ø 如果不是长度限制，缩写应该被避免.当使用缩写时应该遵从下面的缩写规范的规则.缩写应该在项目范围内保持一致并被存档.

Ø 不要使用特殊的字符；对文字数字式字符加以限制.

Ø 在命名时为了更好的标识表与应用程序之间的关系，我们要使用“[function name]|[main module name]＿表名”的形式.

比如: Newegg_customer

Blocked_customer

Abs_customer

EDI_....

MDF_....

Ø 当要修改一个对象的架构时,首先要确认与之存在依存关系的对象不受影响.要查看与之存在依存关系的对象,可以在企业管理器中”右键相应对象”->”ALL TASKS”->”DISPLAY DEPENDENCIES”来查看或者使用系统存储过程SP_DEPENDS来查看:

EXEC SP_DEPENDS 'dbo.GetCategories’

Ø 当底层表结构更改时,视图都应该被重新创建.这个应该特别被注意,特别是视图是使用如”SELECT * FROM table”时.

Ø 强烈建议任何时候都不要使用类似于”SELECT * FROM”的语句.

Ø 当在不存在事务上下文中或者是完整性要求不是很高时，在SELECT语句中使用WITH NOLOCK.

5.5 缩写规范

由于长度的限制而需要使用缩写时,应当遵从以下的规则:

Ø 以分类单词作为名字的起始.

Ø 缩写的第一个字符应该与单词的第一个字母相同,比如,SFER就不是Transfer的有效缩写.

Ø Identify and abbreviate the root word, usually the shortest form of the word.

Ø 缩写时省略元音字符,除非特殊原因，重复字符中将被省略一个。

Ø 缩写不应该暗示到其它的单词（比如：单词“parent”可能被缩写为”PRNT”,但是“PRNT”很容易让人想起单词“PRINT”，一个比较好的缩写就是使用”PSRNT”）

Ø 相似单词的缩写应该一致,比如如果Charge缩写为CHRG,则change应该被缩写为CHNG.

Ø 当组合词或者短语被广泛使用时，并且大多人都能识别出这些缩写时，应该使用他们的首字母缩写，因为大多人都能识别出这些缩写。

5.6 列名

列名应该基于逻辑设计中的属性名,

修饰符: 可选，它以角色名而被大家所熟知（PrimaryPartID, AlternatePartID)

主词（primary word）: 除非是主键，否则不需要。因为表名已经限定列名，所以不必要冗余的加入此信息。

限定词: 可选;附加的描述信息，用来帮助我们更明确的了解数据的意义（InventoryOnHandQuantity, CustomerLastName)

分类词: 需要;用来标识数据的类型，一般列名的最后一个单词(PartID, CountryCode, CustomerName, InvoiceAmount). 下面是一些标准的分类词:

CLASSIFIER DESCRIPTION

Address Street or mailing address data

Age Chronological age in years

Average A numerical average (self-explanatory)

Amount Currency amount -- always is money

Code Code from a specific domain of coded values

Count Count of something -- years, payments, etc.

Date Calendar date

Datetime Date including time

Day Day of month (1 - 31)

Description 　 Brief narrative description (usually of a code)

Duration Span of time, whether days, months, years, etc.

Identifier Unique identifier for something

Image A graphic image, such as a bitmap

Indicator A boolean indicator

Measurement Measurement of physical dimensions

Month Month of year

Name Formal name of something

Number Number (self-explanatory)

Percent Number expressed as a percent

Quantity a number of things

Rate Number expressed as a rate

Ratio A proportion, or expression of relationship in quantity, size, amount, etc. between two things

Text Freeform textual information

Time Time of day

Weight Weight measurement

Year Calendar year or julian year number

下面的ERwin diagram 示例推荐的命名协定：

5.7 存储过程命名

存储过程命名使用上面描述的表，视图和列的命名一样的规则，包括不要使用特殊的字符，大写首词,不要使用组名（比如,myProc1）,不要使用系统保留的“sp_”前缀(比如可以使用up_),使用文字数据式字符，为了使存储过程名字更有意义，名字中应包括“对象”＋“动作”的方式。

存储过程命名示例：

Up_IM_CustomerGet(IM 标识itemmaintain系统使用）

Up_IM_LoginValidate

Up_IM_RegionDataRotate

Up_IM_DailyUsageStatsUpdate

Up_IM_CustomerGetUsingLastName

下面是可选的命名规则，使用“动作”＋“对象”的方式:

Up_IM_BuildSalesPerspectives

Up_IM_InsertSellInFileAudit

5.8游标命名

游标应该以下面的标准来命名:

表名或者对象名字{使用此游标的对象名字}+Cursor

例如:

FiscalMonthCURSOR

EmployeeListCURSOR

5.9 触发器命名

触发器命名应该遵从以下的协定:

表名+ { Ins | Upd | Del}

Ins标识此触发器为insert触发器,UPD标识此触发器为update触发器,同理DEL被用来标识delete触发器:

触发器示例:

CustomerIns

ProductCodeDel

BusinessUnitUpd

5.10 索引命名

索引的命名应该在表空间内唯一,当查看执行计划时可以有效的对索引进行识别..

[IX][类型(U标识Unique,C标识Clustered)][列名(s)]

Ø 当对单列进行索引时,你可能需要使用列的全名.

Ø 当对多列进行索引时,要使用你所能想到的最优的缩写.

Ø 当对一个表的所有列进行索引时,使用ALL单词.

Ø 在多列名中使用下划线以增加可读性.

Ø 不要为索引加上序列号

例如:

IXUC_SalesId (clustered unique)

IXU_SalesDate (unique)

IX_SalesId_MonId_QtrId_WkId (composite index)

IX_MonId_YrId (composite index)

IXC_SalesId (clustered not unique)

5.11 主键和外键命名

主键：对主键进行命名应该遵从以下标准:

PK_表名

例如,主键名

PK_Customer

外键：对外键进行命名时应该遵从以下标准:

ChildTableName_FK_ParentTableName

外键名字示例:

Customer_FK_Country

Sales_FK_Customer

5.12 Check约束命名

Check约束的命名遵从以下的约定:

表名CK{数字}

数字被用来区别同一表中的其它Check约束.

Check约束命名示例:

CustomerCK1

5.13 源文件命名

文件命名应该使用和数据库对象命名相同的规则－包括没有特殊字符，限制名字以避免歧义，大写每个单词的首字符，所有的包括SQL脚本的文件应该以.SQL为结束字符，而不是.SP,.TRG等。可执行的批处理文件应该是以.CMD为扩展名.

5.14 Job的命名

Job命名使用以下方式,其中在” Job名”中要标识出此JOB的功能:

Job_[应用系统名_][数据库名_]Job名/ [storce procedure名]

For Example:

Job_IM_IMDB_backup

5.15 用户自定义函数命名

Ø 满足NESE命名的基本原则

Ø 用户定义的函数使用fn来标识

Ø 名字中应包括“对象”＋“动作”的方式

Ø For example:

Un_IM_CustomerGet(IM 标识itemmaintain系统使用）

5.16 用户自定义数据类型命名

Ø 满足NESE命名的基本原则

Ø 用户定义的函数使用Udt来标识

Ø 用户定义的数据类型

如：

UdtPhone

UdtBirthday

UdtAge

5.17 复制命名

在满足NESE命名的基本原则利用Rp来标识复制

Rp_[DBname]复制名{_[Trn]|[Mrg]|[Snp]}

[Trn]:标识为Transactional Publication

[Mrg]:Merge Publication

[Snp]:Snapshot publication

如：

　 Rp_Foodmart_Trn

6. SQL Server代码规范

6.1 对象创建脚本

使用数据库（USE）

不要在SQL Server源文件使用USE 数据库名语句,这会导致只能在此数据库创建对象,OSQL命令行工具可以在数据库中重定向.

删除对象:

IF Exists语句应该在Drop 对象语句之前执行:

IF object_id(‘tablename’) IS NOT NULL

DROP TABLE TableName

表创建,索引,触发器

在开发过程中,所有的表创建脚本都可以合并为一个项目中的文档中(使用ERwin将会非常将会非常容易).此文档中每个表创建语句的后面应该有Go语句,当系统到达一个稳定点时,应该把文档中的从多个表按照表的不同分到单独的文件以利于维护.这此文档应该放到\TBL子目录下.

在每个创建单独表的文档中,都应该在创建表语句的前面使用if exists() drop table 语句.

每表创建单独的索引脚本文件,并把它们放到\TBL的子目录\INDEX下,命名为<表名>.SQL.在每个创建索引的语句之前,应该使用”if exists() drop…”语句,这样当此索引已经存在时,它将会被先删除然后重新创建.

如果必要,创建单独的触发器脚本,并把它放置在\TBL的子目录 \TRG下.也命名为<表名>.SQL.

主键,外键,Check约束和默认值

所有的约束和默认值定义都应该直接通过ALTER TABLE命令来创建,在创建表的同时对约束和默认值进行嵌入式的定义应该被禁止,为了清晰起见.一个ALTER TABLE语句不应该包括多个对表的更改，我们推荐在每个更改语句之前使用“if exists() alter …. Drop onstraint…”，这样当此约束已经存在时，可以被重新创建。

主键定义有单独的脚本，并放置在\TBL的子目录\PK下。

外键定义也应该有独立的脚本，并放置与\TBL