公司数据库表

㈠ 在公司人事管理数据库中使用数据表Employees 来记录员工信息。

根据选项多次强调“两列”，个人感觉只能选A。
规则与CHECK不同于：
规则可使用于多列，但每列只允许定义一次；
CHECK只用于一列，但一列可定义多个CHECK。

㈡ 公司内部系统的oracle数据库表怎么对接

建议建立中间表来实现，不建议也不需要设置键值关联，建了反而会有问题
最简单的实现方式大概思路就是设计一个中间表（字段只要双方约定好就可以了），通过dblink的方式，他们系统往中间表里插入数据，你们从中间表里获取数据，这样大家互不影响

㈢ 如何用access建立公司员工数据库

很简单的，03一般使用向导来建立数据库就行了，07里初始都是现成的模板来新建，如果都不是你希望使用的模板，点offfice按扭，点新建，在右侧会出现新建文件保存的目录，确定一下就行了，

㈣ 某公司的人事系统数据库中有三张表： 员工表（EMP）,部门表（DEPT）,工资表（SALARY） EMP表结构如下

SELECT
main.dept_name as 部门名称,
count(*) as 在职员工数,
sum(acu_salary) as 实发工资总额
FROM
dept main
INNER JOIN emp a ON main.dept_code = a.dept_code
INNER JOIN salary b ON a.emp_id = b.emp_id
WHERE
-- 1为有效标识
main.alive_flag = '1'
AND a.alive_flag = '1'
AND b.alive_flag = '1'
AND b.`month` = '201101'
GROUP BY
a.dept_code
HAVING
count(*) > 5

㈤ 数据库表与表之间的关系

表与表之间一般存在三种关系，即一对一，一对多，多对多关系。

例如:一个人可以拥有多辆汽车，要求查询某个人拥有的所有车辆。
分析：这种情况其实也可以采用 一张表，但因为一个人可以拥有多辆汽车，如果采用一张表，会造成冗余信息过多。好的设计方式是，人和车辆分别单独建表，那么如何将两个表关联呢？有个巧妙的方法，在车辆的表中加个外键字段(人的编号)即可。

例如：学生选课，一个学生可以选修多门课程，每门课程可供多个学生选择。
分析：这种方式可以按照类似一对多方式建表，但冗余信息太多，好的方式是实体和关系分离并单独建表，实体表为学生表和课程表，关系表为选修表，其中关系表采用联合主键的方式(由学生表主键和课程表主键组成)建表。

什么是视图？

在 sql 中，视图是基于 SQL 语句的结果集的可视化的表。

第一点：
使用视图，可以定制用户数据，聚焦特定的数据。

解释：
在实际过程中，公司有不同角色的工作人员，我们以销售公司为例的话，
采购人员，可以需要一些与其有关的数据，而与他无关的数据，对他没
有任何意义，我们可以根据这一实际情况，专门为采购人员创建一个视
图，以后他在查询数据时，只需select * from view_caigou 就可以啦。

第二点：使用视图，可以简化数据操作。

解释：我们在使用查询时，在很多时候我们要使用聚合函数，同时还要
显示其它字段的信息，可能还会需要关联到其它表，这时写的语句可能
会很长，如果这个动作频繁发生的话，我们可以创建视图，这以后，我
们只需要select * from view1就可以啦～，是不是很方便呀～

第三点：使用视图，基表中的数据就有了一定的安全性

因为视图是虚拟的，物理上是不存在的，只是存储了数据的集合，我们可以
将基表中重要的字段信息，可以不通过视图给用户，视图是动态的数据的集
合，数据是随着基表的更新而更新。同时，用户对视图，不可以随意的更改
和删除，可以保证数据的安全性。

第四点：可以合并分离的数据，创建分区视图

随着社会的发展，公司的业务量的不断的扩大，一个大公司，下属都设有很
多的分公司，为了管理方便，我们需要统一表的结构，定期查看各公司业务
情况，而分别看各个公司的数据很不方便，没有很好的可比性，如果将这些
数据合并为一个表格里，就方便多啦，这时我们就可以使用union关键字，
将各分公司的数据合并为一个视图。

以上，就是我认为视图的作用，实际上很多公司都使用视图来查询数据的。

内连接: 只连接匹配的行
SELECT * from gradeclass gc inner join grade g on gc.grade_id=g.Id，
左外连接: 包含左边表的全部行（不管右边的表中是否存在与它们匹配的行），以及右边表中全部匹配的行
select * from grade g rigth OUTER JOIN gradeclass g on g.grade_id=gc.Id（这里的outer可以省略）
右外连接: 包含右边表的全部行（不管左边的表中是否存在与它们匹配的行），以及左边表中全部匹配的行
select * from grade g rigth OUTER JOIN gradeclass g on g.grade_id=gc.Id（这里的outer可以省略）
全外连接: 包含左、右两个表的全部行，不管另外一边的表中是否存在与它们匹配的行。
交叉连接: 生成笛卡尔积－它不使用任何匹配或者选取条件，而是直接将一个数据源中的每个行与另一个数据源的每个行都一一匹配

㈥ 求教公司的数据库构建有哪些要素

简述数据库设计过程—希望可以帮你

数据库设计(Database Design)是指对于一个给定的应用环境，构造最优的数据库模式，建立数据库及其应用系统，使之能够有效地存储数据，满足各种用户的应用需求（信息要求和处理要求）。

在数据库领域内，常常把使用数据库的各类系统统称为数据库应用系统。

一、数据库和信息系统
(1)数据库是信息系统的核心和基础，把信息系统中大量的数据按一定的模型组织起来，提供存储、维护、检索数据的
功能，使信息系统可以方便、及时、准确地从数据库中获得所需的信息。
(2)数据库是信息系统的各个部分能否紧密地结合在一起以及如何结合的关键所在。
(3)数据库设计是信息系统开发和建设的重要组成部分。
(4)数据库设计人员应该具备的技术和知识：
数据库的基本知识和数据库设计技术
计算机科学的基础知识和程序设计的方法和技巧
软件工程的原理和方法
应用领域的知识

二、数据库设计的特点
数据库建设是硬件、软件和干件的结合
三分技术，七分管理，十二分基础数据
技术与管理的界面称之为逗干件地
数据库设计应该与应用系统设计相结合
结构（数据）设计：设计数据库框架或数据库结构
行为（处理）设计：设计应用程序、事务处理等
结构和行为分离的设计
传统的软件工程忽视对应用中数据语义的分析和抽象，只要有可能就尽量推迟数据结构设计的决策早期的数据库设计致力于数据模型和建模方法研究，忽视了对行为的设计
如图：

三、数据库设计方法简述
手工试凑法
设计质量与设计人员的经验和水平有直接关系
缺乏科学理论和工程方法的支持，工程的质量难以保证
数据库运行一段时间后常常又不同程度地发现各种问题，增加了维护代价
规范设计法
手工设计方
基本思想
过程迭代和逐步求精
规范设计法(续)
典型方法：
(1)新奥尔良（New Orleans）方法：将数据库设计分为四个阶段
S.B.Yao方法：将数据库设计分为五个步骤
I.R.Palmer方法：把数据库设计当成一步接一步的过程
(2)计算机辅助设计
ORACLE Designer 2000
SYBASE PowerDesigner

四、数据库设计的基本步骤
数据库设计的过程(六个阶段)
1.需求分析阶段
准确了解与分析用户需求（包括数据与处理）
是整个设计过程的基础，是最困难、最耗费时间的一步
2.概念结构设计阶段
是整个数据库设计的关键
通过对用户需求进行综合、归纳与抽象，形成一个独立于具体DBMS的概念模型
3.逻辑结构设计阶段
将概念结构转换为某个DBMS所支持的数据模型
对其进行优化
4.数据库物理设计阶段
为逻辑数据模型选取一个最适合应用环境的物理结构（包括存储结构和存取方法）
5.数据库实施阶段
运用DBMS提供的数据语言、工具及宿主语言，根据逻辑设计和物理设计的结果
建立数据库，编制与调试应用程序，组织数据入库，并进行试运行
6.数据库运行和维护阶段
数据库应用系统经过试运行后即可投入正式运行。
在数据库系统运行过程中必须不断地对其进行评价、调整与修改
设计特点:
在设计过程中把数据库的设计和对数据库中数据处理的设计紧密结合起来将这两个方面的需求分析、抽象、设计、实现在各个阶段同时进行，相互参照，相互补充，以完善两方面的设计

设计过程各个阶段的设计描述：
如图：

五、数据库各级模式的形成过程
1.需求分析阶段：综合各个用户的应用需求
2.概念设计阶段：形成独立于机器特点，独立于各个DBMS产品的概念模式(E-R图)
3.逻辑设计阶段：首先将E-R图转换成具体的数据库产品支持的数据模型，如关系模型，形成数据库逻辑模式；然后根据用户处理的要求、安全性的考虑，在基本表的基础上再建立必要的视图(View)，形成数据的外模式
4.物理设计阶段：根据DBMS特点和处理的需要，进行物理存储安排，建立索引，形成数据库内模式

六、数据库设计技巧

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) 检查设计
在开发期间检查数据库设计的常用技术是通过其所支持的应用程序原型检查数据库。换句话说，针对每一种最终表达数据的原型应用，保证你检查了数据模型并且查看如何取出数据。

㈦ 新到公司，发现数据库表建立的时候没有主键与表与表之间没有外键

很多优秀的项目都没有主外键关系的

举个例子，一个张用户表，一张订单表，建立主外键关系
现在要删除这个用户，但是用户曾经有过订单（订单不能删除），你该怎么删除

约束表间关系的除了“主外键”，还有程序的逻辑性，触发器也可以

㈧ 如何用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表中用户自定义的错误消息即可。

------------------------------------------