⑴ sql中表达完整性约束的规则主要有哪几种
1、实体完整性：规定表的每一行在表中是惟一的实体。
2、域完整性：是指表中的列必须满足某种特定的数据类型约束，其中约束又包括取值范围、精度等规定。
3、 参照完整性：是指两个表的主关键字和外关键字的数据应一致，保证了表之间的数据的一致性，防止了数据丢失或无意义的数据在数据库中扩散。
4、用户定义的完整性：不同的关系数据库系统根据其应用环境的不同，往往还需要一些特殊的约束条件。用户定义的完整性即是针对某个特定关系数据库的约束条件，它反映某一具体应用必须满足的语义要求。
(1)sql编码基本原则扩展阅读
完整性约束的类型介绍：
1、与表有关的约束：是表中定义的一种约束。可在列定义时定义该约束，此时称为列约束，也可以在表定义时定义约束，此时称为表约束。
2、域(Domain)约束：在域定义中被定义的一种约束，它与在特定域中定义的任何列都有关系。
3、断言(Assertion)：在断言定义时定义的一种约束，它可以与一个或多个表进行关联。
⑵ SQL Server数据库的高性能优化经验总结
本文主要向大家介绍的是正确优化SQL
Server数据库的经验总结，其中包括在对其进行优化的实际操作中值得大家注意的地方描述，以及对SQL语句进行优化的最基本原则，以下就是文章的主要内容描述。
优化数据库的注意事项：
1、关键字段建立索引。
2、使用存储过程，它使SQL变得更加灵活和高效。
3、备份数据库和清除垃圾数据。
4、SQL语句语法的优化。(可以用Sybase的SQL
Expert，可惜我没找到unexpired的序列号)
5、清理删除日志。
SQL语句优化的基本原则：
1、使用索引来更快地遍历表。
缺省情况下建立的索引是非群集索引，但有时它并不是最佳的。在非群集索引下，数据在物理上随机存放在数据页上。合理的索引设计要建立在对各种查询的分析和预测上。
一般来说：
①.有大量重复值、且经常有范围查询(between,
>,<
，>=,<
=)和order
by、group
by发生的列，可考虑建立群集索引
②.经常同时存取多列，且每列都含有重复值可考虑建立组合索引;
③.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。
2、IS
NULL
与
IS
NOT
NULL
不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。任何在where子句中使用is
null或is
not
null的语句优化器是不允许使用索引的。
3、IN和EXISTS
EXISTS要远比IN的效率高。里面关系到full
table
scan和range
scan。几乎将所有的IN操作符子查询改写为使用EXISTS的子查询。
4、在海量查询时尽量少用格式转换。
5、当在SQL
SERVER
2000中
如果存储过程只有一个参数，并且是OUTPUT类型的，必须在调用这个存储过程的时候给这个参数一个初始的值，否则会出现调用错误。
6、ORDER
BY和GROPU
BY
使用ORDER
BY和GROUP
BY短语，任何一种索引都有助于SELECT的性能提高。注意如果索引列里面有NULL值，Optimizer将无法优化。
7、任何对列的操作都将导致表扫描，它包括SQL
Server数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
8、IN、OR子句常会使用工作表，使索引失效。如果不产生大量重复值，可以考虑把子句拆开。拆开的子句中应该包含索引。
9、SET
SHOWPLAN_ALL>10、谨慎使用游标
在某些必须使用游标的场合，可考虑将符合条件的数据行转入临时表中，再对临时表定义游标进行操作，这样可使性能得到明显提高。
注释：所谓的优化就是WHERE子句利用了索引，不可优化即发生了表扫描或额外开销。经验显示，SQL
Server数据库性能的最大改进得益于逻辑的数据库设计、索引设计和查询设计方面。反过来说，最大的性能问题常常是由其中这些相同方面中的不足引起的。
其实SQL优化的实质就是在结果正确的前提下，用优化器可以识别的语句，充份利用索引，减少表扫描的I/O次数，尽量避免表搜索的发生。其实SQL的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深入研究还会涉及SQL
Server数据库层的资源配置、网络层的流量控制以及操作系统层的总体设计。
⑶ 请问怎么修改MS SQL数据库的编码方式啊
sql server 2000的unicode编码有特殊性，仅仅在rails中使用utf8编码，和把全部rails项目文件格式改成utf8之外，还是不够的。仅仅这样做，只是部分中文字符能够正确处理，而且存入sql server2000中的中文数据，也完全是乱码。正确的配置方法应该如下。
1. ms sql server2000中数据字段全部要选择成n打头的类型，比如ntext，nvarchar等。
2.安装ADO Driver
安装one -click installer 来安装ruby 的话就已经安装了所有连接SQL Server使用的需求包.但是,并没有安装ADO Driver.
这样来安装它：
在Ruby目录下找到这个目录: \ruby\lib\ruby\site_ruby\1.8\DBD .例如:我的Ruby安装在D:\ruby中,所以是这个目录D:\ruby\lib\ruby\site_ruby\1.8\DBD 在该目录中创建一个ADO文件夹. 下载Ruby-DBI,将lib/dbd_ado/ADO.rb文件拷贝到X:/ruby/lib/ruby/site_ruby/1.8/DBD/ADO/ADO.rb
3. 配置database.yml：Java代码
development:
adapter: sqlserver
database: database_name
host: server_name
username: user_name
password: your_pw_here
development:
adapter: sqlserver
database: database_name
host: server_name
username: user_name
password: your_pw_here
4.在environment.rb添加下面代码
require 'win32ole'
WIN32OLE.codepage = WIN32OLE::CP_UTF8
在这里稍微解释下第四部分的设置。sql server 2000中使用的unicode 并非是utf8，ado的默认链接编码都是当前系统设置的code pages相关的。
一般的windows设置都是非unicode的,比如简体中文windows系统下一般都是gb2312, 在rails中database.yml设置encoding: utf8，对于sql server没有任何用处。
为了迫使sql server接受utf8数据，必须修改ado链接的code pages值为utf8，才能让ado部分代码在接受rails传入的utf8数据之后，不做任何额外的处理. 否则的话，ado部分代码会根据当前系统的默认code pages值来处理这里字符数据。
于是在中文windows系统上，从utf8的rails项目中传入的数据，会被当作gb2312编码的数据来传递到sql server2000中，于是sql server2000中存入的数据会成为乱码，也有部分数据在处理过程中出错，导致sql 语句执行出错。比如常见的中文字符右边的单引号会不见的情况。
不设置 WIN32OLE.codepage = WIN32OLE::CP_UTF8,你的整个系统编码配置是这样的
rails（utf8)<-->ado(根据当前系统cp来取得编码,或是gb2312或是其他)<-->sql server 2000 (unicode)
整个系统编码不一至
WIN32OLE.codepage = WIN32OLE::CP_UTF8 这句代码就是为了更改cp值.整个系统编码配置是这样的
rails（utf8)<-->ado(utf8)<-->sql server 2000 (unicode)
整个系统编码一至,整个系统中不会再出现任何乱码.
注：以上转自：jack发表在javaeye网站上的文章，地址：http://www.javaeye.com/topic/53877
database.yml也可以用以下的配置试试（用下面这种的话第1条或许不用，没试过）
⑷ 如何用SQL2005建立一个简单的公司数据库
一份设计合理的数据库，对程序开发可以达到事半功倍的效果，对于后期维护、二次开发的重要性更是不言而喻。
数据设计、实现过程中的注意事件（个人观点）：
1.命名规范：
1）表：模块前缀+英文单词，如 BBS_UserInfo；
2）字段：表前缀+英文单词，如 U_Name；
2.三大范式：
尽量满足数据库设计三大范式。
第一范式（1NF）是指数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。
第二范式（2NF）：要求数据库表中的每个实例或行必须可以被惟一地区分，数据库表中不存在非关键字段对任一候选关键字段的部分函数依赖（部分函数依赖指的是存在组合关键字中的某些字段决定非关键字段的情况），也即所有非关键字段都完全依赖于任意一组候选关键字。
第三范式（3NF）：要求一个数据库表中不包含已在其它表中已包含的非主关键字信息，在第二范式的基础上，数据表中如果不存在非关键字段对任一候选关键字段的传递函数依赖则符合第三范式。
3.数据结构：
建立必要的主外键关系、建立好多表查询联合查询、复杂条件查询的储存过程等等。
4.保留数据库设计文档（这点对于二次开发尤为重要）。
--------------友情分割线（以下为收藏资料，已忘记原出处）--------------
1数据库表及字段命名、设计规范
1.1数据库表数据库表的命名规范：
表的前缀应该用系统或模块的英文名的缩写（全部大写或首字母大写）。如果系统功能简单，没有划分为模块，则可以以系统英文名称的缩写作为前缀，否则以各模块的英文名称缩写作为前缀。例如：如果有一个模块叫做BBS(缩写为BBS),那么你的数据库中的所有对象的名称都要加上这个前缀：BBS_ + 数据库对象名称，BBS_CustomerInfo标示论坛模块中的客户信息表
表的名称必须是易于理解，能表达表的功能的英文单词或缩写英文单词，无论是完整英文单词还是缩写英文单词，单词首字母必须大写。如果当前表可用一个英文单词表示的，请用完整的英文单词来表示；例如：系统资料中的客户表的表名可命名为：SYS_Customer。如果当前表需用两个或两个以上的单词来表示时，尽量以完整形式书写，如太长可采用两个英文单词的缩写形式；例如：系统资料中的客户物料表可命名为：SYS_CustItem。
表名称不应该取得太长（一般不超过三个英文单词）。
在命名表时，用单数形式表示名称。例如，使用 Employee，而不是 Employees。
对于有主明细的表来说。明细表的名称为：主表的名称 + 字符Dts。例如：采购定单的名称为：PO_Order，则采购定单的明细表为：PO_OrderDts
对于有主明细的表来说，明细表必须包含两个字段：主表关键字、SN，SN字段的类型为int型，目的为与主表关键字联合组成明细表的关键字，以及标示明细记录的先后顺序，如1,2,3……。
表必须填写描述信息
后台表名尽量与前台表名相同，后台独有的表应以_b作为后缀。如r_gggd_b
1.2表字段
命名规范
数据库字段的命名必须遵循以下规范：
采用有意义的字段名。字段的名称必须是易于理解，能表达字段功能的英文单词或缩写英文单词，单词首字母必须大写，一般不超过三个英文单词。例如:人员信息表中的电话号码可命名为：Telephone或Tel。产品明细表中的产品名称可用ProctName表示。（推荐一般用完整的英文单词）。
系统中所有属于内码字段（仅用于标示唯一性和程序内部用到的标示性字段），名称取为：“ID”，采用整型或长整型数，具体根据可能的数据量确定，增加记录时取最大值加1，该字段通常为主关键字。
系统中属于是业务范围内的编号的字段，其代表一定的业务信息，比如资料信息和单据的编号，这样的字段建议命名为：“Code”，其数据类型为varchar，该字段需加唯一索引。
在命名表的列时，不要重复表的名称；例如，在名为 Employee 的表中避免使用名为 EmployeeLastName 的字段。
不要在列的名称中包含数据类型。
设计规范
所有字段在设计时，除以下数据类型timestamp、image、datetime、smalldatetime、uniqueidentifier、binary、sql_variant、binary 、varbinary外，必须有默认值。字符型的默认值为一个空字符值串’’；数值型的默认值为数值0；逻辑型的默认值为数值0；
其中：系统中所有逻辑型中数值0表示为“假”；数值1表示为“真”。
datetime、smalldatetime类型的字段没有默认值，必须为NULL。
当字段定义为字符串形时建议使用varchar而不用nvarchar。
建议在大多数表中（如报销单，申请单），应都有以下字段：
字段名说明类型默认值
CreatorID创建者int0
CreatedTime创建时间DatetimeNULL
字段的描述
数据库中每个字段的描述(Description)如下：
尽量遵守第三范式的标准（3NF）。
表内的每一个值只能被表达一次
表内的每一行都应当被唯一的标示
表内不应该存储依赖于其他键的非键信息
如果字段事实上是与其它表的关键字相关联而未设计为外键引用，需建索引。
如果字段与其它表的字段相关联，需建索引。
如果字段需做模糊查询之外的条件查询，需建索引。
除了主关键字允许建立簇索引外，其它字段所建索引必须为非簇索引。
字段必须填写描述信息
2存贮过程命名及设计规范
2.1命名规范
存贮过程的命名请遵循以下命名规范：USP _ + 系统模块缩写（与表前缀类似）+_ + 功能标识 + 代表存贮过程操作的主要表名（不带前缀）或功能的英文单词或英文单词缩写。
如果一个存贮过程只对一个表进行操作，建议存贮过程的名称就用存贮过程所操作的表的表名（不带前缀）。这样有利于根据表名找到相应的存贮过程。
为了在众多的存贮过程中能很快的找到并维护存贮过程，我们按存贮过程的作用将系统的存贮过程
进行以下的分类及命名：（以下示例假设存贮过程所在的模块名为ORG）
作用第一前缀第二前缀名
(功能标识)示例
用于新增的存贮过程USP_ORGAddUSP_ORG_Add_Employee
用于修改的存贮过程USP_ORGUptUSP _ORG_Upt_Employee
用于删除的存贮过程USP_ORGDelUSP _ORG_Del_Employee
用于单据查询的存贮过程USP_ORGQryUSP _ORG_Qry_Employee
用于报表统计的存贮过程USP_ORGRptUSP _ORG_Rpt_GetEmployee
用于一些特殊过程处理的存贮过程USP_ORGOthUSP _ORG_Oth_SetSystemMessage
如果系统中的存贮过程只有一级，则遵照以上规则命名，如果存在多级，则需要区分其属于哪一级，具体为：USP + 所属的级次 + _ + 后面的部分
例如：
1.USP1_ORG_Add_Subject （没有调用其它存贮过程）
2.USP2_ORG_Upt_Subject (调用了第1级的存贮过程)
3.USP3_ORG_Qry_Subject (调用了第2级的存贮过程)
2.2设计规范
在存贮过程中必须说明以下内容：
目的：说明此存贮过程的作用。
作者：首次创建此存贮过程的人的姓名。在此请使用中文全名，不允许使用英文简称。
创建日期：创建存贮过程时的日期。
修改记录：
修改记录需包含修改顺序号、修改者、修改日期、修改原因，修改时不能直接在原来的代码上修改，也不能删除原来的代码，只能先将原来的代码注释掉，再重新增加正确的代码。修改顺序号的形式为：log1，log2，log3。。。，根据修改次数顺序增加，同时在注释掉的原来的代码块和新增的正确代码块前后注明修改顺序号。
对存贮过程各参数及变量的中文注解。
示例如下：
/*
目的：根据部门与物料和会计区间查询生产现场领料汇总报表
作者：李奇
创建日期：2002-12-11
*/
/*
修改顺序号：log1
修改者：刘敏
修改日期：2002.12.22
修改原因：（具体原因详细描述）
*/
CREATE PROCEDURE [dbo].[USP_GetLMSSum]
@ProctionType int=1, --生产类型（1-自制；0-委外加工）
@DeptID int=0, --生产部门
@ItemID int=0, --物料
@StartDate datetime='2002-11-26',--会计区间开始日期
@EndDate datetime='2002-12-25'--会计区间截止日期
AS
/*
log1 old
--自制领料
INSERT INTO #LMSDts
SELECT dbo.iStockBill.DeptID, dbo.fDept.DeptName,
dbo.mLMS.ItemID AS ItemInterID, dbo.fItem.ItemID, dbo.fItem.ItemName,
ISNULL(dbo.fItem.Model, N'') AS Model, ISNULL(dbo.fUnit.UnitName, N'')
AS UnitName, dbo.mLMS.Qty, dbo.mLMS.TransType, dbo.mWO.OrderType,
dbo.mLMS.CreateTime
end log1 old
*/
--log1 new
--自制领料
INSERT INTO #LMSDts
SELECT dbo.iStockBill.DeptID, dbo.fDept.DeptName,
dbo.mLMS.ItemID AS ItemInterID, dbo.fItem.ItemID, dbo.fItem.ItemName,
ISNULL(dbo.fItem.Model, N'') AS Model, ISNULL(dbo.fUnit.UnitName, N'')
AS UnitName, dbo.mLMS.Qty, dbo.mLMS.TransType, dbo.mWO.OrderType,
dbo.mLMS.CreateTime
--end log1 new
3 视图命名规范
3.1命名规范
视图的命名请遵循以下命名规范：UV _ + 系统模块缩写（与表前缀类似）+_ + 功能标识 + 代表视图查询的主要表名（不带前缀）或功能的英文单词或英文单词缩写。
如果一个视图只对一个表进行查询，建议视图的名称就用视图所查询的表的表名（不带前缀）。这样有利于根据表名找到相应的视图。
为了在众多的视图中能很快的找到并维护视图，我们按其作用将系统的视图
进行以下的分类及命名：（以下示例假设视图所在的模块名为ORG）
作用第一前缀第二前缀名
(功能标识)示例
用于单据查询的视图UV_ORGQryUV_ORG_Qry_Employee
用于报表统计的视图UV_ORGRptUV_ORG_Rpt_GetEmployee
用于一些特殊过程处理的视图UV_ORGOthUV_ORG_Oth_SetSystemMessage
如果系统中的视图只有一级，则遵照以上规则命名，如果存在多级，则需要区分其属于哪一级，具体为：UV + 所属的级次 + _ + 后面的部分
例如：
UV1_ORG_Add_Subject （没有调用其它视图）
UV2_ORG_Upt_Subject (调用了第1级的视图)
UV3_ORG_Qry_Subject (调用了第2级的视图)
3.2 设计规范
在视图中必须说明以下内容：
目的：说明此视图的作用。
创建者：首次创建此视图的人的姓名。在此请使用中文全名，不允许使用英文简称。
修改者、修改日期、修改原因：如果有人对此视图进行了修改，则必须在此视图的前面加注修改者姓名、修改日期及修改原因。
对视图各参数及变量的中文注解。
示例如下：
/*
目的：查询本月所要培训的科目
创建：加菲猫
时间：2001-3-3
修改者：Dyan 修改日期：2002-12-11
修改原因及内容：学员不需要培训，将不需要培训的课程去掉。
修改者：周明 修改日期：2002-4-2
修改原因及内容：增加一门新课程
*/
CREATE VIEW dbo.USP_AddSubject
AS
SELECT SubjectIId AS 课程编号
FROM dbo.ZfLocaleDecide
3.3 存储过程和事务处理
如果事务处理在存储过程返回时的嵌套层次与执行时的层次不同，SQL Server会显示信息提示事务处理嵌套失控。因为存储过程并不异常终止该批处理，在执行和确认随后的语句时，过程内的rollback tran 会导致数据完整性损失。
在编写存储过程时，应遵守以下原则：
1．过程对@@trancount应无净改变。
2．仅当存储过程发出begin tran语句时，才发出rollback tran。
3.4 其他注意事项
存储过程应该坚实可靠的，因为它们是驻留在服务器中，被频繁使用的。应仔细检查参数的有效性，并在有问题时返回出错信息。应确保参数的数据类型和被比较的栏的数据类型匹配，从而避免数据类型匹配错误。在每个SQL语句之后要检查@@error。
4触发器编码规范
4.1命名规范
触发器名为相应的表名加上后缀
Insert触发器加'_i'，Delete触发器加'_d'，Update触发器加'_u'，如：r_bch_i，r_bch_d，r_bch_u。
4.2 设计规范
在触发器中必须说明以下内容：
目的：说明此触发器的作用。
创建者：首次创建人的姓名。在此请使用中文全名，不允许使用英文简称。
修改者、修改日期、修改原因：如果有人对此视图进行了修改，则必须在此视图的前面加注修改者姓名、修改日期及修改原因。
对其中各参数及变量的中文注解。
4.3范例
下面通过一个例子，说明触发器编程中应遵守的规范：
/* delete related r_a according to deleted table */
CREATE TRIGGER r_a_d ON r_a
FOR DELETE
AS
IF @@ROWCOUNT = 0 -no rows deleted
RETURN
/* delete r_b table related to deleted table */
DELETE r_b
FROM r_b b, deleted d
WHERE b.id=d.id
IF @@ERROR != 0
BEGIN
RAISERROR("Error occurred deleting related records", 16, 1)
ROLLBACK TRAN
END
RETURN
作以下几点说明：
1．检查是否有行被修改。注意：不论数据是否被修改，触发器都会引发，执行情况取决于T-SQL语句的执行，而和任何潜在的where子句是否执行无关。
2．因为被删除行在该表中不再可用，所以应在被删除的表中查看。
3．检查T-SQL语句的返回代码，以捕获任何出错条件。
4.4 事务过程中的触发器
1．触发器内的rollback将所有工作返回至最外层的begin tran，完成触发器内的处理并异常终止当前的批处理。
2．不可以从触发器内部返回至某个已命名的事务过程，这将产生运行错误，挂起所有工作并终止批处理。
5 SQL语言编码规范
5.1所有关键字必须大写。
如：INSERT、UPDATE、DELETE、SELECT及其子句。
IF……ELSE、CASE、DECLARE等。
所有函数及其参数中除用户变量以外的部分必须大写。
在定义变量时用到的数据类型必须小写。
所有关键字必须大写
5.2注释
注释可以包含在批处理中。在触发器、存储过程中包含描述性注释将大大增加文本的可读性和可维护性。本规范建议：
1、注释以英文为主。
实际应用中，发现以中文注释的SQL语句版本在英文环境中不可用。为避免后续版本执行过程中发生某些异常错误，建议使用英文注释。
2、注释尽可能详细、全面。
创建每一数据对象前，应具体描述该对象的功能和用途。
传入参数的含义应该有所说明。如果取值范围确定，也应该一并说明。取值有特定含义的变量（如boolean类型变量），应给出每个值的含义。
3、注释语法包含两种情况：单行注释、多行注释
单行注释：注释前有两个连字符（--），最后以行尾序列（CR-LF）结束。一般，对变量、条件子句可以采用该类注释。
多行注释：符号/*和*/之间的内容为注释内容。对某项完整的操作建议使用该类注释。
4、注释简洁，同时应描述清晰。
5函数注释：
编写函数文本--如触发器、存储过程以及其他数据对象--时，必须为每个函数增加适当注释。该注释以多行注释为主，主要结构如下：
/************************************************************************
*name : --函数名
*function : --函数功能
*input : --输入参数
*output : --输出参数
*author : --作者
*CreateDate : --创建时间
*UpdateDate : --函数更改信息（包括作者、时间、更改内容等）
*************************************************************************/
CREATE PROCEDURE sp_xxx
…
5.3条件执行语句if…else
条件语句块（statenemt block，以 begin…end为边界）仅在if子句的条件为真时才被执行。
为提高代码的可读性，建议嵌套不多于5层。还有，当嵌套层次太多时，应该考虑是否可以使用case语句。
5.4重复执行while和跳转语句goto
需要多次执行的语句，可以使用while结构。其中，控制while循环的条件在任何处理开始之前需要先执行一次。循环体中的保留字break无条件的退出while循环，然后继续处理后续语句；保留字continue重新计算while条件，如果条件为真，则从循环开始处重新执行各语句。
使用跳转语句goto和标签label也可以方便地实现循环和其他更灵活的操作。SQL SERVER仅具有单通道语法分析器，因此不能解析对尚未创建的对象所做的前向参考。换言之，跳转到某标签的后续语句应该是可执行的（如不存在可能尚未创建的数据对象）。
5.5书写格式
数据库服务器端的触发器和存储过程是一类特殊的文本，为方便开发和维护，提高代码的易读性和可维护性。规范建议按照分级缩进格式编写该文本。
顺序执行的各命令位于同一级；条件语句块（statenemt block，以 begin…end为边界）位于下一级，类推。
SQL语句是该文本的主体。为适应某些教复杂的用户需求，SQL语句可能比较庞大。为方便阅读和维护，规范建议按照SQL语句中系统保留字的关键程度再划分为三级。具体分级请参照下表。其中，非系统保留字（如字段名、数据表名、标点符号）相对本级保留字再缩进一级。多个连续的非保留字可以分行书写，也可以写在同一行。当WHERE包含的条件子句教复杂时，应该每行只写一个条件分句，并为重要的条件字句填写单行注释。
在保证基本缩进格式的前提下，可以通过对齐某些重要关键字（如条件关键字AND、OR，符号 = 、 <> 等）来进一步提高文本的易读性和可维护性。
相邻两级的缩进量为10个空格。这也是ISQL编辑器默认的文本缩进量。另外，在ISQL编辑器中，一个TAB键也相当于10个空格。
6数据对象的国际化
6.1关于数据对象的命名
数据对象和变量的命名一律采用英文字符。禁止使用中文命名。其他命名注意事项和规范请参考2命名规则。
6.2关于RAISERROR
SQL SERVER 系统的RAISERROR命令能够把某个出错情况返回给调用过程，这对说明调用过程的执行情况很有必要；同时可以部分避免客户端的冗余操作。另外，结合系统存储过程sp_addmessage和sp_dropmessage可以方便实现数据对象在SQL SERVER端的国际化。
SQL SERVER的MASTER数据库中有错误信息数据表sysmessages，专门用于存储系统和用户的错误提示及相关信息（如错误ID号、错误等级、状态）。用户可以调用sp_addmessage和sp_dropmessage预先将各类错误信息记入该数据表。其中，不同的错误信息用错误ID号区分。在编写存储过程代码时，调用RAISERROR函数从错误信息表sysmessages中引用相关错误ID号的错误信息。
由于0~50000的值是保留为 SQL SERVER使用的，所以用户自定义错误信息的错误ID号必须大于50000。
RAISERROR的语法如下：
RAISERROR ({msg_id | msg_str}, severity, state )
本规范建议存储过程以RAISERROR和RETURN返回。
举例如下：
l第一步：生成该错误信息
/*insert a error message into the master..sysmessages*/
sp_addMessage 50001 ,16 ,'Can"t update the primary key from table %s'
l第二步：执行存储过程sp_xxx，异常返回时引用上述错误信息
CREATE PROCEDURE sp_xxx
BEGIN
…
RAISERROR(50001 ,16 ,1 ,'r_a') -- Can"t update the primary key from table r_a
ROLLBACK TRAN
RETURN(1)
END
l第三步：在DELPHI调用中，通过EDBEngineError捕捉该错误
try
sp_test.execProc ;
except
on e :EDBEngineError
if e.errors[1].errorcode = 13059 then
/*hint 'Can"t update the primary key from table r_a'*/
showMessage(e.errors[1].message)
end ;
l第四步：当不再使用该错误信息时，应该从错误信息表中删除相应数据
sp_dropMessage 50001
l第五步：错误提示信息国际化
用相应语言替换master..sysmessages表中用户自定义的错误消息即可。
------------------------------------------
⑸ sql数据库设计
一、数据库设计过程
数据库技术是信息资源管理最有效的手段。数据库设计是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，有效存储数据，满足用户信息要求和处理要求。
数据库设计中需求分析阶段综合各个用户的应用需求（现实世界的需求），在概念设计阶段形成独立于机器特点、独立于各个DBMS产品的概念模式（信息世界模型），用E-R图来描述。在逻辑设计阶段将E-R图转换成具体的数据库产品支持的数据模型如关系模型，形成数据库逻辑模式。然后根据用户处理的要求，安全性的考虑，在基本表的基础上再建立必要的视图（VIEW）形成数据的外模式。在物理设计阶段根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。
1. 需求分析阶段
需求收集和分析，结果得到数据字典描述的数据需求（和数据流图描述的处理需求）。
需求分析的重点是调查、收集与分析用户在数据管理中的信息要求、处理要求、安全性与完整性要求。
需求分析的方法：调查组织机构情况、调查各部门的业务活动情况、协助用户明确对新系统的各种要求、确定新系统的边界。
常用的调查方法有： 跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录。
分析和表达用户需求的方法主要包括自顶向下和自底向上两类方法。自顶向下的结构化分析方法（Structured Analysis，简称SA方法）从最上层的系统组织机构入手，采用逐层分解的方式分析系统，并把每一层用数据流图和数据字典描述。
数据流图表达了数据和处理过程的关系。系统中的数据则借助数据字典（Data Dictionary，简称DD）来描述。
数据字典是各类数据描述的集合，它是关于数据库中数据的描述，即元数据，而不是数据本身。数据字典通常包括数据项、数据结构、数据流、数据存储和处理过程五个部分(至少应该包含每个字段的数据类型和在每个表内的主外键)。
数据项描述＝｛数据项名，数据项含义说明，别名，数据类型，长度，
取值范围，取值含义，与其他数据项的逻辑关系｝
数据结构描述＝｛数据结构名，含义说明，组成:｛数据项或数据结构｝｝
数据流描述＝｛数据流名，说明，数据流来源，数据流去向，
组成:｛数据结构｝，平均流量，高峰期流量｝
数据存储描述＝｛数据存储名，说明，编号，流入的数据流，流出的数据流，
组成:｛数据结构｝，数据量，存取方式｝
处理过程描述＝｛处理过程名，说明，输入:｛数据流｝，输出:｛数据流｝,
处理:｛简要说明｝｝
2. 概念结构设计阶段
通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型，可以用E-R图表示。
概念模型用于信息世界的建模。概念模型不依赖于某一个DBMS支持的数据模型。概念模型可以转换为计算机上某一DBMS支持的特定数据模型。
概念模型特点：
(1) 具有较强的语义表达能力，能够方便、直接地表达应用中的各种语义知识。
(2) 应该简单、清晰、易于用户理解，是用户与数据库设计人员之间进行交流的语言。
概念模型设计的一种常用方法为IDEF1X方法，它就是把实体-联系方法应用到语义数据模型中的一种语义模型化技术，用于建立系统信息模型。
使用IDEF1X方法创建E-R模型的步骤如下所示:
2.1 第零步——初始化工程
这个阶段的任务是从目的描述和范围描述开始，确定建模目标，开发建模计划，组织建模队伍，收集源材料，制定约束和规范。收集源材料是这阶段的重点。通过调查和观察结果，业务流程，原有系统的输入输出，各种报表，收集原始数据，形成了基本数据资料表。
2.2 第一步——定义实体
实体集成员都有一个共同的特征和属性集，可以从收集的源材料——基本数据资料表中直接或间接标识出大部分实体。根据源材料名字表中表示物的术语以及具有“代码”结尾的术语，如客户代码、代理商代码、产品代码等将其名词部分代表的实体标识出来，从而初步找出潜在的实体，形成初步实体表。
2.3 第二步——定义联系
IDEF1X模型中只允许二元联系，n元联系必须定义为n个二元联系。根据实际的业务需求和规则，使用实体联系矩阵来标识实体间的二元关系，然后根据实际情况确定出连接关系的势、关系名和说明，确定关系类型，是标识关系、非标识关系（强制的或可选的）还是非确定关系、分类关系。如果子实体的每个实例都需要通过和父实体的关系来标识，则为标识关系，否则为非标识关系。非标识关系中，如果每个子实体的实例都与而且只与一个父实体关联，则为强制的，否则为非强制的。如果父实体与子实体代表的是同一现实对象，那么它们为分类关系。
2.4 第三步——定义码
通过引入交叉实体除去上一阶段产生的非确定关系，然后从非交叉实体和独立实体开始标识侯选码属性，以便唯一识别每个实体的实例，再从侯选码中确定主码。为了确定主码和关系的有效性，通过非空规则和非多值规则来保证，即一个实体实例的一个属性不能是空值，也不能在同一个时刻有一个以上的值。找出误认的确定关系，将实体进一步分解，最后构造出IDEF1X模型的键基视图（KB图）。
2.5 第四步——定义属性
从源数据表中抽取说明性的名词开发出属性表，确定属性的所有者。定义非主码属性，检查属性的非空及非多值规则。此外，还要检查完全依赖函数规则和非传递依赖规则，保证一个非主码属性必须依赖于主码、整个主码、仅仅是主码。以此得到了至少符合关系理论第三范式的改进的IDEF1X模型的全属性视图。
2.6 第五步——定义其他对象和规则
定义属性的数据类型、长度、精度、非空、缺省值、约束规则等。定义触发器、存储过程、视图、角色、同义词、序列等对象信息。
3. 逻辑结构设计阶段
将概念结构转换为某个DBMS所支持的数据模型（例如关系模型），并对其进行优化。设计逻辑结构应该选择最适于描述与表达相应概念结构的数据模型，然后选择最合适的DBMS。
将E-R图转换为关系模型实际上就是要将实体、实体的属性和实体之间的联系转化为关系模式,这种转换一般遵循如下原则：
1）一个实体型转换为一个关系模式。实体的属性就是关系的属性。实体的码就是关系的码。
2）一个m:n联系转换为一个关系模式。与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。
3）一个1:n联系可以转换为一个独立的关系模式，也可以与n端对应的关系模式合并。如果转换为一个独立的关系模式，则与该联系相连的各实体的码以及联系本身的属性均转换为关系的属性，而关系的码为n端实体的码。
4）一个1:1联系可以转换为一个独立的关系模式，也可以与任意一端对应的关系模式合并。
5）三个或三个以上实体间的一个多元联系转换为一个关系模式。与该多元联系相连的各实体的码以及联系本身的属性均转换为关系的属性。而关系的码为各实体码的组合。
6）同一实体集的实体间的联系，即自联系，也可按上述1:1、1:n和m:n三种情况分别处理。
7）具有相同码的关系模式可合并。
为了进一步提高数据库应用系统的性能，通常以规范化理论为指导，还应该适当地修改、调整数据模型的结构，这就是数据模型的优化。确定数据依赖。消除冗余的联系。确定各关系模式分别属于第几范式。确定是否要对它们进行合并或分解。一般来说将关系分解为3NF的标准，即：
表内的每一个值都只能被表达一次。
•?表内的每一行都应该被唯一的标识（有唯一键）。
表内不应该存储依赖于其他键的非键信息。
4. 数据库物理设计阶段
为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）。根据DBMS特点和处理的需要，进行物理存储安排，设计索引，形成数据库内模式。
5. 数据库实施阶段
运用DBMS提供的数据语言（例如SQL）及其宿主语言（例如C），根据逻辑设计和物理设计的结果建立数据库，编制与调试应用程序，组织数据入库，并进行试运行。 数据库实施主要包括以下工作：用DDL定义数据库结构、组织数据入库 、编制与调试应用程序、数据库试运行
6. 数据库运行和维护阶段
数据库应用系统经过试运行后即可投入正式运行。在数据库系统运行过程中必须不断地对其进行评价、调整与修改。包括：数据库的转储和恢复、数据库的安全性、完整性控制、数据库性能的监督、分析和改进、数据库的重组织和重构造。
建模工具的使用
为加快数据库设计速度，目前有很多数据库辅助工具（CASE工具），如Rational公司的Rational Rose，CA公司的Erwin和Bpwin，Sybase公司的PowerDesigner以及Oracle公司的Oracle Designer等。
ERwin主要用来建立数据库的概念模型和物理模型。它能用图形化的方式，描述出实体、联系及实体的属性。ERwin支持IDEF1X方法。通过使用ERwin建模工具自动生成、更改和分析IDEF1X模型，不仅能得到优秀的业务功能和数据需求模型，而且可以实现从IDEF1X模型到数据库物理设计的转变。ERwin工具绘制的模型对应于逻辑模型和物理模型两种。在逻辑模型中，IDEF1X工具箱可以方便地用图形化的方式构建和绘制实体联系及实体的属性。在物理模型中，ERwin可以定义对应的表、列，并可针对各种数据库管理系统自动转换为适当的类型。
设计人员可根据需要选用相应的数据库设计建模工具。例如需求分析完成之后，设计人员可以使用Erwin画ER图，将ER图转换为关系数据模型，生成数据库结构；画数据流图，生成应用程序。
二、数据库设计技巧
1. 设计数据库之前（需求分析阶段）
1) 理解客户需求，询问用户如何看待未来需求变化。让客户解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。
2) 了解企业业务可以在以后的开发阶段节约大量的时间。
3) 重视输入输出。
在定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。
举例：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。
4) 创建数据字典和ER 图表
ER 图表和数据字典可以让任何了解数据库的人都明确如何从数据库中获得数据。ER图对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对SQL 表达式的文档化来说这是完全必要的。
5) 定义标准的对象命名规范
数据库各种对象的命名必须规范。
2. 表和字段的设计（数据库逻辑设计）
表设计原则
1) 标准化和规范化
数据的标准化有助于消除数据库中的数据冗余。标准化有好几种形式，但Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，遵守3NF 标准的数据库的表设计原则是：“One Fact in One Place”即某个表只包括其本身基本的属性，当不是它们本身所具有的属性时需进行分解。表之间的关系通过外键相连接。它具有以下特点：有一组表专门存放通过键连接起来的关联数据。
举例：某个存放客户及其有关定单的3NF 数据库就可能有两个表：Customer 和Order。Order 表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向Customer 表里包含该客户信息的那一行。
事实上，为了效率的缘故，对表不进行标准化有时也是必要的。
2) 数据驱动
采用数据驱动而非硬编码的方式，许多策略变更和维护都会方便得多，大大增强系统的灵活性和扩展性。
举例，假如用户界面要访问外部数据源（文件、XML 文档、其他数据库等），不妨把相应的连接和路径信息存储在用户界面支持表里。还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状态等），那么产生工作流的数据也可以存放在数据库里。角色权限管理也可以通过数据驱动来完成。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。
3) 考虑各种变化
在设计数据库的时候考虑到哪些数据字段将来可能会发生变更。
举例，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存储客户信息时，在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。
字段设计原则
4) 每个表中都应该添加的3 个有用的字段
•?dRecordCreationDate，在VB 下默认是Now()，而在SQL Server 下默认为GETDATE()
•?sRecordCreator，在SQL Server 下默认为NOT NULL DEFAULT USER
•?nRecordVersion，记录的版本标记；有助于准确说明记录中出现null 数据或者丢失数据的原因
5) 对地址和电话采用多个字段
描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。
6) 使用角色实体定义属于某类别的列
在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联关系，从而可以实现自我文档化。
举例：用PERSON 实体和PERSON_TYPE 实体来描述人员。比方说，当John Smith, Engineer 提升为John Smith, Director 乃至最后爬到John Smith, cio 的高位，而所有你要做的不过是改变两个表PERSON 和PERSON_TYPE 之间关系的键值，同时增加一个日期/时间字段来知道变化是何时发生的。这样，你的PERSON_TYPE 表就包含了所有PERSON 的可能类型，比如Associate、Engineer、Director、CIO 或者CEO 等。还有个替代办法就是改变PERSON 记录来反映新头衔的变化，不过这样一来在时间上无法跟踪个人所处位置的具体时间。
7) 选择数字类型和文本类型尽量充足
在SQL 中使用smallint 和tinyint 类型要特别小心。比如，假如想看看月销售总额，总额字段类型是smallint，那么，如果总额超过了$32,767 就不能进行计算操作了。
而ID 类型的文本字段，比如客户ID 或定单号等等都应该设置得比一般想象更大。假设客户ID 为10 位数长。那你应该把数据库表字段的长度设为12 或者13 个字符长。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。
8) 增加删除标记字段
在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性。
3. 选择键和索引（数据库逻辑设计）
键选择原则：
1) 键设计4 原则
•?为关联字段创建外键。
•?所有的键都必须唯一。
•?避免使用复合键。
•?外键总是关联唯一的键字段。
2) 使用系统生成的主键
设计数据库的时候采用系统生成的键作为主键，那么实际控制了数据库的索引完整性。这样，数据库和非人工机制就有效地控制了对存储数据中每一行的访问。采用系统生成键作为主键还有一个优点：当拥有一致的键结构时，找到逻辑缺陷很容易。
3) 不要用用户的键(不让主键具有可更新性)
在确定采用什么字段作为表的键的时候，可一定要小心用户将要编辑的字段。通常的情况下不要选择用户可编辑的字段作为键。
4) 可选键有时可做主键
把可选键进一步用做主键，可以拥有建立强大索引的能力。
索引使用原则：
索引是从数据库中获取数据的最高效方式之一。95%的数据库性能问题都可以采用索引技术得到解决。
1) 逻辑主键使用唯一的成组索引，对系统键（作为存储过程）采用唯一的非成组索引，对任何外键列采用非成组索引。考虑数据库的空间有多大，表如何进行访问，还有这些访问是否主要用作读写。
2) 大多数数据库都索引自动创建的主键字段，但是可别忘了索引外键，它们也是经常使用的键，比如运行查询显示主表和所有关联表的某条记录就用得上。
3) 不要索引memo/note 字段，不要索引大型字段（有很多字符），这样作会让索引占用太多的存储空间。
4) 不要索引常用的小型表
不要为小型数据表设置任何键，假如它们经常有插入和删除操作就更别这样作了。对这些插入和删除操作的索引维护可能比扫描表空间消耗更多的时间。
4. 数据完整性设计（数据库逻辑设计）
1) 完整性实现机制：
实体完整性：主键
参照完整性：
父表中删除数据：级联删除；受限删除；置空值
父表中插入数据：受限插入；递归插入
父表中更新数据：级联更新；受限更新；置空值
DBMS对参照完整性可以有两种方法实现：外键实现机制（约束规则）和触发器实现机制
用户定义完整性：
NOT NULL；CHECK；触发器
2) 用约束而非商务规则强制数据完整性
采用数据库系统实现数据的完整性。这不但包括通过标准化实现的完整性而且还包括数据的功能性。在写数据的时候还可以增加触发器来保证数据的正确性。不要依赖于商务层保证数据完整性；它不能保证表之间（外键）的完整性所以不能强加于其他完整性规则之上。
3) 强制指示完整性
在有害数据进入数据库之前将其剔除。激活数据库系统的指示完整性特性。这样可以保持数据的清洁而能迫使开发人员投入更多的时间处理错误条件。
4) 使用查找控制数据完整性
控制数据完整性的最佳方式就是限制用户的选择。只要有可能都应该提供给用户一个清晰的价值列表供其选择。这样将减少键入代码的错误和误解同时提供数据的一致性。某些公共数据特别适合查找：国家代码、状态代码等。
5) 采用视图
为了在数据库和应用程序代码之间提供另一层抽象，可以为应用程序建立专门的视图而不必非要应用程序直接访问数据表。这样做还等于在处理数据库变更时给你提供了更多的自由。
5. 其他设计技巧
1) 避免使用触发器
触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。
2) 使用常用英语（或者其他任何语言）而不要使用编码
在创建下拉菜单、列表、报表时最好按照英语名排序。假如需要编码，可以在编码旁附上用户知道的英语。
3) 保存常用信息
让一个表专门存放一般数据库信息非常有用。在这个表里存放数据库当前版本、最近检查/修复（对Access）、关联设计文档的名称、客户等信息。这样可以实现一种简单机制跟踪数据库，当客户抱怨他们的数据库没有达到希望的要求而与你联系时，这样做对非客户机/服务器环境特别有用。
4) 包含版本机制
在数据库中引入版本控制机制来确定使用中的数据库的版本。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库结构。把版本信息直接存放到数据库中更为方便。
5) 编制文档
对所有的快捷方式、命名规范、限制和函数都要编制文档。
采用给表、列、触发器等加注释的数据库工具。对开发、支持和跟踪修改非常有用。
对数据库文档化，或者在数据库自身的内部或者单独建立文档。这样，当过了一年多时间后再回过头来做第2 个版本，犯错的机会将大大减少。
6) 测试、测试、反复测试
建立或者修订数据库之后，必须用用户新输入的数据测试数据字段。最重要的是，让用户进行测试并且同用户一道保证选择的数据类型满足商业要求。测试需要在把新数据库投入实际服务之前完成。
7) 检查设计
在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。
三、数据库命名规范
1. 实体（表）的命名
1) 表以名词或名词短语命名，确定表名是采用复数还是单数形式，此外给表的别名定义简单规则（比方说，如果表名是一个单词，别名就取单词的前4 个字母；如果表名是两个单词，就各取两个单词的前两个字母组成4 个字母长的别名；如果表的名字由3 个单词组成，从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成4 字母长的别名，其余依次类推）
对工作用表来说，表名可以加上前缀WORK_ 后面附上采用该表的应用程序的名字。在命名过程当中，根据语义拼凑缩写即可。注意，由于ORCLE会将字段名称统一成大写或者小写中的一种，所以要求加上下划线。
举例：
定义的缩写 Sales: Sal 销售；
Order: Ord 订单；
Detail: Dtl 明细；
则销售订单明细表命名为：Sal_Ord_Dtl;
2) 如果表或者是字段的名称仅有一个单词，那么建议不使用缩写，而是用完整的单词。
举例：
定义的缩写 Material Ma 物品；
物品表名为：Material, 而不是 Ma.
但是字段物品编码则是：Ma_ID;而不是Material_ID
3) 所有的存储值列表的表前面加上前缀Z
目的是将这些值列表类排序在数据库最后。
4) 所有的冗余类的命名(主要是累计表)前面加上前缀X
冗余类是为了提高数据库效率，非规范化数据库的时候加入的字段或者表
5) 关联类通过用下划线连接两个基本类之后，再加前缀R的方式命名,后面按照字母顺序罗列两个表名或者表名的缩写。
关联表用于保存多对多关系。
如果被关联的表名大于10个字母，必须将原来的表名的进行缩写。如果没有其他原因，建议都使用缩写。
举例：表Object与自身存在多对多的关系,则保存多对多关系的表命名为：R_Object；
表 Depart和Employee;存在多对多的关系；则关联表命名为R_Dept_Emp
2. 属性（列）的命名
1) 采用有意义的列名，表内的列要针对键采用一整套设计规则。每一个表都将有一个自动ID作为主健,逻辑上的主健作为第一组候选主健来定义,如果是数据库自动生成的编码，统一命名为：ID;如果是自定义的逻辑上的编码则用缩写加“ID”的方法命名。如果键是数字类型，你可以用_NO 作为后缀；如果是字符类型则可以采用_CODE 后缀。对列名应该采用标准的前缀和后缀。
举例：销售订单的编号字段命名：Sal_Ord_ID；如果还存在一个数据库生成的自动编号，则命名为：ID。
2) 所有的属性加上有关类型的后缀，注意，如果还需要其它的后缀，都放在类型后缀之前。
注: 数据类型是文本的字段，类型后缀TX可以不写。有些类型比较明显的字段，可以不写类型后缀。
3) 采用前缀命名
给每个表的列名都采用统一的前缀，那么在编写SQL表达式的时候会得到大大的简化。这样做也确实有缺点，比如破坏了自动表连接工具的作用，后者把公共列名同某些数据库联系起来。
3. 视图的命名
1) 视图以V作为前缀，其他命名规则和表的命名类似；
2) 命名应尽量体现各视图的功能。
4. 触发器的命名
触发器以TR作为前缀，触发器名为相应的表名加上后缀，Insert触发器加'_I'，Delete触发器加'_D'，Update触发器加'_U'，如：TR_Customer_I，TR_Customer_D，TR_Customer_U。
5. 存储过程名
存储过程应以'UP_'开头，和系统的存储过程区分，后续部分主要以动宾形式构成，并用下划线分割各个组成部分。如增加代理商的帐户的存储过程为'UP_Ins_Agent_Account'。
6. 变量名
变量名采用小写，若属于词组形式，用下划线分隔每个单词，如@my_err_no。
7. 命名中其他注意事项
1) 以上命名都不得超过30个字符的系统限制。变量名的长度限制为29（不包括标识字符@）。
2) 数据对象、变量的命名都采用英文字符，禁止使用中文命名。绝对不要在对象名的字符之间留空格。
3) 小心保留词，要保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突
5) 保持字段名和类型的一致性，在命名字段并为其指定数据类型的时候一定要保证一致性。假如数据类型在一个表里是整数，那在另一个表里可就别变成字符型了。
⑹ MYSQL与SQL的区别
1.根本的区别是它们遵循的基本原则
二者所遵循的基本原则是它们的主要区别：开放vs保守。SQL服务器的狭隘的，保守的存储引擎与MySQL服务器的可扩展，开放的存储引擎绝然不同。虽然你可以使用SQL服务器的Sybase引擎，但MySQL能够提供更多种的选择，如MyISAM, Heap, InnoDB, and Berkeley DB。MySQL不完全支持陌生的关键词，所以它比SQL服务器要少一些相关的数据库。同时，MySQL也缺乏一些存储程序的功能，比如MyISAM引擎联支持交换功能。
2.性能：先进的MySQL
纯粹就性能而言，MySQL是相当出色的，因为它包含一个缺省桌面格式MyISAM。MyISAM 数据库与磁盘非常地兼容而不占用过多的CPU和内存。MySQL可以运行于Windows系统而不会发生冲突，在UNIX或类似UNIX系统上运行则更好。你还可以通过使用64位处理器来获取额外的一些性能。因为MySQL在内部里很多时候都使用64位的整数处理。Yahoo!商业网站就使用MySQL作为后台数据库。
当提及软件的性能，SQL服务器的稳定性要比它的竞争对手强很多。但是，这些特性也要付出代价的。比如，必须增加额外复杂操作，磁盘存储，内存损耗等等。如果你的硬件和软件不能充分支持SQL服务器，我建议你最好选择其他如DBMS数据库，因为这样你会得到更好的结果。
3.发行费用：MySQL不全是免费，但很便宜
当提及发行的费用，这两个产品采用两种绝然不同的决策。对于SQL服务器，获取一个免费的开发费用最常的方式是购买微软的Office或者Visual Studio的费用。但是，如果你想用于商业产品的开发，你必须还要购买SQL Server Standard Edition。学校或非赢利的企业可以不考虑这一附加的费用。
4.安全功能
MySQL有一个用于改变数据的二进制日志。因为它是二进制，这一日志能够快速地从主机上复制数据到客户机上。即使服务器崩溃，这一二进制日志也会保持完整，而且复制的部分也不会受到损坏。
在SQL服务器中，你也可以记录SQL的有关查询，但这需要付出很高的代价。
安全性
这两个产品都有自己完整的安全机制。只要你遵循这些安全机制，一般程序都不会出现什么问题。这两者都使用缺省的IP端口，但是有时候很不幸，这些IP也会被一些黑客闯入。当然，你也可以自己设置这些IP端口。
恢复性:先进的SQL服务器
恢复性也是MySQL的一个特点，这主要表现在MyISAM配置中。这种方式有它固有的缺欠，如果你不慎损坏数据库，结果可能会导致所有的数据丢失。然而，对于SQL服务器而言就表现得很稳键。SQL服务器能够时刻监测数据交换点并能够把数据库损坏的过程保存下来。
供你参考，祝你好运!!!
⑺ sql server的对象命名规则是什么
自己搜索一下就是了，我给你一段：
为了提供完善的数据库管理机制，SQL Server 设计了严格的命名规则。在创建或引用数据库实体，如表、索引、约束等时，必须遵守SQL Server 的命名规则，否则有可能发生一些难以预料和检查的错误。
本文将讲述：标识符的分类和格式规定；数据库对象的命名规定与使用原则。希望对您会有所帮助。
标识符分类
SQL Server的所有对象，包括服务器、数据库以及数据库对象，如表、视图、列、索引、触发器、存储过程、规则、默认值和约束等都可以有一个标识符。对绝大多数对象来说，标识符是必不可少的，但对某些对象如约束来说，是否规定标识符是可选的。对象的标识符一般在创建对象时定义，作为引用对象的工具使用。
例如下面的SQL语句：
Create table student
(
id int primary key,
name varchar(20)
)
这个例子创建了一个表格，表格的名字是一个标识符：student；表格中定义了两列，列的名字分别是id,name,他们都是合法的标识符。这个例子还定义另外一个未命名的主键约束。
SQL Server一共定义了两种类型的标识符：规则标识符（Regular identifier）和界定标识符(Delimited identifier)。
规则标识符
规则标识符严格遵守标识符有关格式的规定。所以在T-SQL语句中凡是规则标识符都不必使用界定符，如[]和‘’，来进行界定。
如上述例子中使用的表名student 就是一个规则标识符，在student上不必添加界定符。
界定标识符
界定标识符是那些使用了如[]和‘’等界定符号来进行位置限定的标识符，使用了界定标识符，既可以遵守标识符命名规则，也可以不遵守标识符命名规则。
Select * from [student] 是要从student 表格中查询出所有的数据与
Select * from student 等效。
为什么呢？因为在“[]”中的标识符遵守标识符命名规则，“[]”被忽略不计。
但如果是不遵守标识符命名规则的标识符，那么在T-SQL语句中必须使用界定符号加以限定，如：
Select * from [my table]
Where [order]=10
在这个例子中，必须使用界定标识符，因为在from子句中的标识符my talbe中含有空格，而where子句中的标识符order 是系统保留字(在查询分析器里“order”变蓝色)。这两个标识符都不遵守标识符命名规则，必须使用界定符，否则无法通过代码编译。
标识符格式
标识符格式的规定，其具体内容如下：
标识符的首字母必须是以下两种情况之一：
所有在统一码(Unicode)2.0标准规定的字符，包括26个英文字母a-z和A-Z，以及其他一些语言字符，如汉字。例如可以给一个表格命名为“学生基本情况”。下划线“-”、“@”或“#”。
标识符首字母后的字符可以是：
所有在统一码(Unicode)2.0标准规定的字符，包括26个英文字母a-z和A-Z，以及其他一些语言字符，如汉字。下划线“-”、“@”、“$”或“#”。
0,1,2,3,4,5,6,7,8,9。
标识符不允许是T-SQL的保留字。
由于T-SQL不区分大小写，所以无论是保留字的大写还是小写都不允许使用。
标识符内部不允许有空格或特殊字符。
Select * from stu[de]nt –编译器将返回错误信息。因为在标识符stu[de]nt中包含了特殊字符“[”和“]”，所以在编译上述语句时出错。
?
以某些特殊符号开头的标识符在SQL Server系统中具有特定的含义。如“@”开头的标识符表示这是一个局部变量或是一个函数的参数；以“#”开头的标识符表示这是一个临时表或存储过程；一个以“##”开头的标识符表示这是一个全局的临时数据库对象。T-SQL的全局变量以标志“@@”开头。为避免同这些全局变量混淆，建议不要使用“@@”作为标识符的开始。
无论是界定标识符还是规则标识符都最多只能容纳128个字符，对于本地的临时表最多可以有116个字符。
对象命名规则
SQL Server 2000 的数据库对象名字由1-128个字符组成，不区分大小写。在一个数据库中创建了一个数据库对象后，数据库对象的全名应该由服务器名、数据库名、拥有者名和对象名这四个部分组成，格式如下：
[[[server.][database].][owner_name].]object_name 命名必须都要符合标识符的规定。
在实际引用对象时，可以省略其中某部分的名称，只留下空白的位置。
实例的命名习惯
在SQL Server 2000中默认实例的名字采用计算机名，实例的名字一般由计算机名字和实例名字两部分组成。
总之，正确掌握数据库的命名和引用方式是用好SQL Server 2000的前提，也有助于用户理解SQL Server 2000中的其他内容。
⑻ 两位大类加6位流水号用SQL语句怎样生成商品编码
零售服装商品标识代码的编码方法
服装企业在为零售服装产品编制商品条码的代码（以下简称“商品标识代码”）时，应当遵循唯一性、无含义性和稳定性的原则。
1．唯一性
根据GB 12904《商品条码》国家标准的强制性要求，商品名称、商标、种类、规格、数量、包装类型等基本特征属性有一项不同时，商品标识代码就应当不同，这就是编制商品标识代码所应当遵循的唯一性原则，俗称“一品一码”原则。
对于服装产品来说，其基本特征属性一般包括品种、面料、款式、规格、颜色等。这些基本特征属性一旦确定，一般就可以确定唯一的“一款”服装产品。下面举例说明服装企业如何按照唯一性原则编制零售商品标识代码。
例如，某服装企业申请了厂商识别代码69290001。现在有一款新的产品要上市，按照表2-1之结构二，需要分配4位商品项目代码，如0001，相应的校验码为2，则该款服装产品的完整商品标识代码为6929000100012。其后如有第二款产品上市时，应当分配另一个4位商品项目代码，如0002，并得到另一个完整的商品标识代码6929000100029。企业如果将商品项目代码0000～9999这10000个号码全部用完，再生产新产品时，就需要申请一个新的厂商识别代码（如69290002）。此时，虽然后面的商品项目代码（如0001）会和厂商识别代码为69290001时的商品项目代码重复，但由于厂商识别代码不同，整个13位商品标识代码也就不同，不会导致重码。
唯一性原则是编制商品标识代码所应当遵守的最基本原则，也是最重要的一条原则。在商业POS自动结算系统中和服装企业商品管理信息系统中，不同的商品是靠不同的代码来区别的。假如把两种不同的商品用同一代码来标识，违反唯一性原则，会导致商品管理信息系统的混乱，给销售商、消费者和服装企业带来经济损失。当然，“唯一性”是相对的，如果一款新品中还有各种细小的差别（例如钮扣的颜色、形状不同），而服装企业不需要考虑这种细小的差别对销售、配送是否带来影响，编制商品标识代码时就可以对这些细小的差别不予考虑，对存在细小差别的服装产品赋予相同的标识代码。有时，对一些产品管理比较简单的服装企业来说，可能不需要统计同一小类产品的局部款式、规格、颜色的差别对产品的销售、配送是否有影响，则可以将仅在这些方面存在差别的产品认为是一款产品，赋予相同的商品标识代码。不过，商品标识代码分配得越“笼统”，可以得到的服装产品属性信息也就越少，所以不同的企业应根据自己的商品管理需要确定产品的“相同”或“不同”，从而决定商品标识代码的“相同”或“不同”。
需要特别注意的是，基本特征属性完全相同，但因在不同地区销售而售价不同的两批服装产品，不应分配不同的商品标识代码。例如，完全相同的衬衫，在一个城市售价为100元，而同时在另一个城市售价为80元，但它们在出厂时应赋予相同的商品标识代码。为了通过编码与条码符号对不同地区销售的相同产品进行区分，可以采用本章第五节提到的附加属性代码及相应条码符号来表示。
2．无含义性
商品条码具有全球通用性，这就要求其代码长度不能随意。EAN/UCC-13代码只能由13位数字组成。在我国，一个服装企业申请一个前缀码为692或693的厂商识别代码最多只能编制10000款服装产品。因此，为了不浪费代码资源，企业编制服装商品标识代码时一般只能采取无含义编码，而且通常采用流水号编码，也就是“有一款新品编一个代码”。
用上述13位商品标识代码标识一款服装产品，是为了给该款产品一个全球唯一的关键字，所有关于该产品各种属性信息的描述全部依靠计算机数据库系统进行管理。
3．稳定性
一款服装产品被赋予一个商品标识代码后，如果产品本身没有变化，就不能改变其商品标识代码。即使售价发生变化，也只能改变销售管理信息系统的产品价格，而不能改变商品标识代码。但是下列情况下需要改变商品标识代码：
l 产品的新变体取代了原产品；
l 产品的轻微变化对销售的影响比较明显，企业需要考虑这种影响。
另外，由于服装产品的更新换代非常快，所以对于不再生产的产品，其商品标识代码可以在适当时候赋给新的产品，以节省代码资源。一般在一款服装产品停产2年半后可以把相应的商品标识代码重新赋给新的产品。总之，在不影响产品信息管理、不导致市场混乱的前提下，服装企业应及时启用停产产品的商品标识代码，以尽量节省代码资源。
服装商品标识代码编码的唯一性、无含义性和稳定性是三个非常重要的原则。服装企业在编制商品标识代码时，必须遵守这三个原则，科学、规范地进行编码，充分发挥商品条码的作用。
采用商品条码来标识服装产品，企业往往担心编码容量不够用。其实，这种担心是不必要的。只要采用无含义编码，现有的商品条码系统成员至少有10000个号码可以使用（前缀码为692、693）。而且服装产品生命周期短，往往一款产品经过一两年就不再生产了，停产后两三年该标识代码就可以赋给别的产品。即使少数企业的产品众多，10000个代码容量确实不够用，中国物品编码中心还允许系统成员根据需要申请多个厂商识别代码，每增加一个厂商识别代码就意味着给企业增加了10000个代码容量。针对个别大型服装企业，中国物品编码中心还可以提供专门的编码容量解决方案。
服装产品的基本特征属性繁多，商品标识代码数量普遍比较大，一般至少达数百个，多的达几万甚至几十万个。这些代码信息一旦出现混乱，可能给服装企业的产品管理造成严重影响。因此企业必须十分重视商品标识代码的赋码管理工作，实行专人管理，尽量采用计算机自动赋码和编码信息管理，确保编码信息的安全有序。