在数据库开发过程中,数据库、表、字段、视图、存储过程等的命名规则,谁有这方面的文档,谢谢!

时间:2022-09-23 13:53:25
在数据库开发过程中,数据库、表、字段、视图、存储过程等的命名规则,谁有这方面的文档,谢谢!

59 个解决方案

#1


建议可以使用匈牙利命名法

#2


我使用的规则:
1。数据库:按实际用途取名,没有标准;
2。表:t_开头,加上英文名或缩写;
3。字段:具有一定意义的英文缩写;
4。视图:v_开头,加上英文名或缩写;
5。存储过程:p_开头,加上英文名或缩写;
仅供参考。

#3


happydreamer(绝对的黑):能否将匈牙利命名法将给大家,多谢。

#4


to happydreamer(绝对的黑):匈牙利命名法编程可以,但用在数据库就显得有些力不从心了,希望您具体一点

#5


我的规则:
tbl001, tbl002
其它类是,
然后建立说明文档文件,绝对清楚。

#6


我们公司在开发象分销系统、ERP这类管理软件的时候也跟: tj_dns(愉快的登山者)说的差不多
还有就是同一个模块的前缀最好一致,如库存管理模块 kcgl_XXXXXXX
基础数据:jcsj_XXXXX等等
这样清晰明了

#7


同志们,我要的是谁有标准文档啊,不是只举一个例子。

#8


我把我们公司的盗给你,呵呵

2 命名规则
2.1 表名
XXX相关表以r_作为前缀,YYY相关表以t_作为前缀。如r_acc 、t_bcc。
后台表名尽量与前台表名相同,后*有的表应以_b作为后缀。如r_gggd_b。
命名应尽量反映存储的数据内容。
2.2 视图名
视图以v_作为前缀。由于前台无视图,故不需加_b。
命名应尽量体现各视图的功能。
2.3 触发器名
触发器名为相应的表名加上后缀,Insert触发器加'_i',Delete触发器加'_d',Update触发器加'_u',如:r_bch_i,r_bch_d,r_bch_u。
2.4 存储过程名
存储过程应以'sp_'开头,后续部分主要以动宾形式构成,并用下划线分割各个组成部分。如增加BSC机架的DRT单板的存储过程为'sp_ins_board_drt'。
2.5 变量名
变量名采用小写,若属于词组形式,用下划线分隔每个单词,如@my_err_no。
2.6 命名中其他注意事项
以上命名都不得超过30个字符的系统限制。
变量名的长度限制为29(不包括标识字符@)。
数据对象、变量的命名都采用英文字符。禁止使用中文命名。
 
3 编程结构和描述
SQL SERVER系统中,一个批处理是从客户传给服务器的一个完整的包,可以包含若干条SQL语句。批处理中的语句是作为一组去进行语法分析、编译和执行的。触发器、存储过程等数据对象则是将批处理永久化的方法。
3.1 注释
注释可以包含在批处理中。在触发器、存储过程中包含描述性注释将大大增加文本的可读性和可维护性。本规范建议:
1、 注释以英文为主。
    实际应用中,发现以中文注释的SQL语句版本在英文环境中不可用。为避免后续版本执行过程中发生某些异常错误,建议使用英文注释。
2、 注释尽可能详细、全面。
创建每一数据对象前,应具体描述该对象的功能和用途。
传入参数的含义应该有所说明。如果取值范围确定,也应该一并说明。取值有特定含义的变量(如boolean类型变量),应给出每个值的含义。
3、 注释语法包含两种情况:单行注释、多行注释
单行注释:注释前有两个连字符(--),最后以行尾序列(CR-LF)结束。一般,对变量、条件子句可以采用该类注释。
多行注释:符号/*和*/之间的内容为注释内容。对某项完整的操作建议使用该类注释。
4、 注释简洁,同时应描述清晰。
3.2 函数注释:
编写函数文本--如触发器、存储过程以及其他数据对象--时,必须为每个函数增加适当注释。该注释以多行注释为主,主要结构如下:
/************************************************************************
*name        :               --函数名
*function    :               --函数功能
*input       :               --输入参数
*output      :               --输出参数
*author      :               --作者
*CreateDate  :              --创建时间
*UpdateDate  :               --函数更改信息(包括作者、时间、更改内容等)
*************************************************************************/
CREATE PROCEDURE sp_xxx

3.3 条件执行语句if…else
条件语句块(statenemt block,以 begin…end为边界)仅在if子句的条件为真时才被执行。为提高代码的可读性,建议嵌套不多于5层。还有,当嵌套层次太多时,应该考虑是否可以使用case语句。
3.4 重复执行while和跳转语句goto
需要多次执行的语句,可以使用while结构。其中,控制while循环的条件在任何处理开始之前需要先执行一次。循环体中的保留字break无条件的退出while循环,然后继续处理后续语句;保留字continue重新计算while条件,如果条件为真,则从循环开始处重新执行各语句。
使用跳转语句goto和标签label也可以方便地实现循环和其他更灵活的操作。SQL SERVER仅具有单通道语法分析器,因此不能解析对尚未创建的对象所做的前向参考。换言之,跳转到某标签的后续语句应该是可执行的(如不存在可能尚未创建的数据对象)。
3.5 书写格式
数据库服务器端的触发器和存储过程是一类特殊的文本,为方便开发和维护,提高代码的易读性和可维护性。规范建议按照分级缩进格式编写该文本。
顺序执行的各命令位于同一级;条件语句块(statenemt block,以 begin…end为边界)位于下一级,类推。
SQL语句是该文本的主体。为适应某些教复杂的用户需求,SQL语句可能比较庞大。为方便阅读和维护,规范建议按照SQL语句中系统保留字的关键程度再划分为三级。具体分级请参照下表。其中,非系统保留字(如字段名、数据表名、标点符号)相对本级保留字再缩进一级。多个连续的非保留字可以分行书写,也可以写在同一行。当WHERE包含的条件子句教复杂时,应该每行只写一个条件分句,并为重要的条件字句填写单行注释。
在保证基本缩进格式的前提下,可以通过对齐某些重要关键字(如条件关键字AND、OR,符号 = 、 <> 等)来进一步提高文本的易读性和可维护性。
相邻两级的缩进量为10个空格。这也是ISQL编辑器默认的文本缩进量。另外,在ISQL编辑器中,一个TAB键也相当于10个空格。

注:按照功能,四类SQL语句(SELECT、INSERT、UPDATE、DELETE)的关键字可以划分为三类:主关键字、次关键字、一般关键字。如下表所示:
主关键字 次关键字 一般关键字
SELECTINSERT (INTO)UPDATEDELETE  FROMWHEREVALUESINSERT…SELECT…FROM语句中的SELECT和FROM ANDORBETWEENINLIKE


3.6 字体
系统保留字应大写,包括系统公共变量等。其他字符(如用户自定义变量、用户自定义数据对象名)小写。
需要特殊强调的部分可以大写。
一条完整注释语句的首字符应大写。对某变量、某条件字句的注释可以全部使用小写。

通过下一节中生成表r_a的删除触发器的实例可以部分说明对象命名、注释、基本书写格式和字符大小写方面的一些注意事项。

4 触发器编程规范
4.1 范例
下面通过一个例子,说明触发器编程中应遵守的规范:

/* 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.2 事务过程中的触发器
1. 触发器内的rollback将所有工作返回至最外层的begin tran,完成触发器内的处理并异常终止当前的批处理。
2. 不可以从触发器内部返回至某个已命名的事务过程,这将产生运行错误,挂起所有工作并终止批处理。
5 存储过程编程规范
5.1 带有参数的执行
在执行存储过程时,可以通过名字来制定参数,这样可以用任何顺序传递参数,而且自动起到注释的作用,因此建议编程时使用这种方法。
5.2 缺省参数值
把参数的缺省值定为null,这是捕获在过程内调用存储过程所产生的错误的常用方法,不应让标准服务器消息报告参数丢失。在给定缺省之后,可以校验该缺省值并在存储过程内采取措施。
注意,当附值SELECT语句不返回行时,局部变量将保持在SELECT语句执行之前所具有的值。建议使用系统提供的某些全局变量(如@@ROWCOUNT)检测SELECT返回的结果。
5.3 返回值
每个存储过程自动返回一个整数型的状态值:成功完成时返回0,而返回-1~-99表示SQL Server检测到了错误。以下为SQL Server系统常用的返回状态码:
值 含义
    0 Procedure was executed successfully
  ?-1 Object missing
  ?-2 Datatype error occurred
  ?-3 Process was chosen as deadlock victim
 ? -4 Permission error occurred
  ?-5 Syntax error occurred
 ? -6 Miscellaneous user error occurred
  ?-7 Resource error, such as out of space, occurred
 ? -8 Non-fatal internal problem encountered
  ?-9 System limit was reached
??-10 Fatal internal inconsistency occurred
??-11 Fatal internal inconsistency occurred
??-12 Table or index is corrupt
??-13 Database is corrupt
  ?-14 Hardware error occurred
在程序中,用return语句可指定大于0或小于-99的返回值,调用程序可以设置局部变量接收和检查返回状态。
5.4 存储过程和事务处理
如果事务处理在存储过程返回时的嵌套层次与执行时的层次不同,SQL Server会显示信息提示事务处理嵌套失控。因为存储过程并不异常终止该批处理,在执行和确认随后的语句时,过程内的rollback tran 会导致数据完整性损失。
在编写存储过程时,应遵守以下原则:
1. 过程对@@trancount应无净改变。
2. 仅当存储过程发出begin tran语句时,才发出rollback tran。
5.5 其他注意事项
存储过程应该坚实可靠的,因为它们是驻留在服务器中,被频繁使用的。应仔细检查参数的有效性,并在有问题时返回出错信息。应确保参数的数据类型和被比较的栏的数据类型匹配,从而避免数据类型匹配错误。在每个SQL语句之后要检查@@error。

6 数据对象的国际化
6.1 关于数据对象的命名
数据对象和变量的命名一律采用英文字符。禁止使用中文命名。其他命名注意事项和规范请参考2命名规则。
6.2 关于RAISERROR
SQL SERVER 系统的RAISERROR命令能够把某个出错情况返回给调用过程,这对说明调用过程的执行情况很有必要;同时可以部分避免客户端的冗余操作。另外,结合系统存储过程sp_addmessage和sp_dropmessage可以方便实现数据对象在SQL SERVER端的国际化。
SQL SERVER的MASTER数据库中有错误信息数据表sysmessages,专门用于存储系

#9


to  sky_blue(老衲) :谢谢!谢谢!,不过文档开始的“XXX相关表以r_作为前缀,YYY相关表以t_作为前缀”,XXX,YYY什么意思,thanks

#10


XXX,YYY是我们产品的名字,我注掉了。呵呵

#11


后台表,前台表什么意思?thanks

#12


◆匈牙利命名法
匈牙利命名法是一名匈牙利程序员发明的,而且他在微软工作了多年。此命名法就是通过微软的各种产品和文档传出来的。多数有经验的程序员,不管他们用的是哪门儿语言,都或多或少在使用它

这种命名法的基本原则是:

变量名=属性+类型+对象描述

即一个变量名是由三部分信息组成,这样,程序员很容易理解变量的类型、用途,而且便于记忆。

下边是一些推荐使用的规则例子,你可以挑选使用,也可以根据个人喜好作些修改再用之。

⑴属性部分:

全局变量: g_

常量 : c_

类成员变量: m_

⑵类型部分:

指针: p

句柄: h

布尔型: b

浮点型: f 

无符号: u

⑶描述部分:

初始化: Init

临时变量: Tmp

目的对象: Dst

源对象: Src

窗口: Wnd 


下边举例说明:

hwnd: h表示句柄,wnd表示窗口,合起来为“窗口句柄”。

m_bFlag: m表示成员变量,b表示布尔,合起来为:“某个类的成员变量,布尔型,是一个状态标志”。

#13


匈牙利命名法
这个方法可能很多人都听说过,包括我在内的一些人也试图去使用它,可是还是觉得自己的好,但是现在看来这种想法是错误的。再解释解释吧。这些符号可以多个同时使用,顺序是先m_,(这上标记指成员变量)再指针,再简单数据类型,再其他。例如:m_lpszStr, 表示指向一个以0字符结尾的字符串的长指针成员变量。

a Array
b Boolean
by Byte
c Char //有符号型字符
cb Char Byte //无符号型字符(没多大用处)
cr ColorRef //颜色参考值
cx,cy Length of x,y (ShortInt) //坐标差(长度)
dw Double Word
fn Function
h Handle
i Integer
m_ Member of a class
n Short Integer
np Near Pointer
p Pointer lp Long Pointer
s String
sz String with Zero End //以字符'\0'结尾的字符串
tm Text //文本内容
w Word
x,y Coordinate //坐标

类名一般没有说明字符,例如theApp. 用在其他类中加m_就行。要注意的是:某些类也有类似于匈牙利命名法的缩写。例如:CStatusBar m_wndStatusBar;这里的wnd表示窗口类,但是这种命名法不是标准的匈牙利命名法的一部分。


http://www.longen.org/E-K/detaile~k/Hungary.htm

#14


来偷学:)

#15


UP

#16


I++先!谢谢各位!

#17


学习...

#18


来学习...小@_@小,今天刚刚换的名

#19


楼上的写的都是真好,我们公司居然用中文字符命名库,表。我利取说采用楼上的这几位高手的意见,却不采取,可悲。请问用中言语命名有什么优劣请给说明分析一下好吗?谢了。

#20


只有SB才会用中文命名数据库对象!

#21


谢谢 happydreamer(绝对的黑) 的匈牙利命名法,呵呵,还有我也是一个SB,因为我用中文命名表对象和字段对象

#22


我也赞成使用中文命名表名和字段名等,这样清晰易懂! 使用中文命名对系统并无什么影响,开发时也不需要总是翻阅说明文档,为何简单的事情不做,一定要读死书使用英文呢?

楼上用英文高手的能说说用中文弊端吗? 
(写程序切换输入法,移植难,的除外,重要说说对系统的影响!

#23


行有行规啦,自己看得清楚明白就可以啦

#24


个人认为匈牙利命名法用在C等开发语言中比较好,SQL中可以参考它但不必拘泥于它。毕竟数据库中的对象主要是表,视图,触发器,而不是int ,byte,array,指针之类。

#25


补充一点,对前面 sky_blue(老衲) 推荐的命名规范我比较欣赏,但同时由于其文中提出对Stored Procedure的命名加前缀'sp_'应有商榷的余地,因为master表中也有'sp_'开头的System Procedure,我在一本专业SQLServer书上看到,作者建议使用'up_'意为User Procedure,我以前也习惯用sp_命名自己的Stored Procedure不过现在为了规范,还是改为使用up_,当然个人也可以使用自己认为合适的前缀来命名.不过既然要走规范化编程道路,最好还是避免定义那些容易使别人产生混淆的名称.

另外使用中文命名数据库对象包括其他程序语言中变量名的朋友们,我前面说SB可能严重一点.我也不是什么权威并不能很好的给出中文命名就有什么弊端的解释,但是全世界的程序员都约定俗成以E文为标准程序语言的大环境下,不要把所谓有'中国特色'的逻辑带入程序设计的世界中来.

#26


个人认为,如果使用中文命名没有什么弊端,就应该从解决问题的方便性去考滤命名方式.为何一定要拘泥于一种所谓的标准,标准是外国人订的,肯定是以英文为主,谁教我们使用E文,书,书是哪来的,外国人写的,当然是E文标准了.

我们的目的是要能轻松方便的解决问题.整个系统在中文环境下应用,库结构非常清晰,不用总是翻阅说明文档.而且有时说明文档不一定能说明问题.况且,中文 NT2000与SQL2000内核都使用和允许使用中文.

我使用E文有如下问题:
1 可读性差. 看一条SQL语句不知道它在干什么.
2 表达的意思不清晰.如果以英文单词作表名和字段名,除非所有程序员都是英文高手,看得懂所有行业的术语,否则就可能要翻字典了.
3 按一定的规则命名,重名多.很多人使用拼音缩写,但如果有相似或相近的拼音,就会分不清楚,况且拼音有时也不一定读得很准.

所以,为我们为何简单的事情不做,非要搞得复杂才算是所谓的"标准"呢

#27


gz

#28


我有一篇这样的文档
不过主要是delphi方面的,希望能够对大家有所帮助:
太长了,大家慢慢看吧!

#29


Delphi 6 程序员代码编写标准指南

一、序言
二、通用源代码格式规则
2.1 缩格
2.2 页边空格
2.3 Begin…End 配对
2.4 代码文件中通用符号含义
三、Object Pascal
3.1 括号
3.2 保留字和关键字
3.3 过程和函数(例程)
    3.3.1 命名/格式化
    3.3.2 形式参数
        3.3.2.1 格式化
        3.3.2.2 命名
        3.3.2.3 参数的排序
        3.3.2.4 常量参数
        3.3.2.5 名称的冲突
3.4 变量
    3.4.1 变量的命名和格式
    3.4.2 局部变量
    3.4.3 全局变量的使用
3.5 类型
    3.5.1 大写约定
        3.5.1.1 浮点指针类型
        3.5.1.2 枚举类型
        3.5.1.3 变数和ole变数类型
    3.5.2 结构类型
        3.5.2.1 数组类型
        3.5.2.2 记录类型
3.6 语句
    3.6.1 if 语句
    3.6.2 case 语句
        3.6.2.1 一般性话题
        3.6.2.2 格式
    3.6.3 while 语句
    3.6.4 for 语句
    3.6.5 repeat 语句
    3.6.6 with  语句
        3.6.6.1 一般话题
        3.6.6.2 格式
3.7 结构异常处理
    3.7.1 一般话题
    3.7.2 try…finally的使用
    3.7.3 try…except的使用
    3.7.4 try…except…else的使用
3.8 类类型
    3.8.1 命名和格式
    3.8.2 域
        3.8.2.1 命名/格式
        3.8.2.2 可视化
    3.8.3 方法
        3.8.3.1 命名/格式
        3.8.3.2 使用静态的方法
        3.8.3.3 使用虚拟/动态的方法
        3.8.3.4 使用抽象的方法
        3.8.3.5 属性存取方法
    3.8.4 属性
        3.8.4.1 命名/格式
        3.8.4.2 使用存取的方法

#30


四、文件
4.1 工程文件
    4.1.1 命名
4.2 窗体文件
    4.2.1 命名
4.3 数据模板文件
    4.3.1 命名
4.4 远端数据模板文件
    4.4.1 命名
4.5 Unit文件
    4.5.1 通用Unit结构
        4.5.1.1 unit的名字
        4.5.1.2 uses子句
        4.5.1.3 interface部分
        4.5.1.4 implementation部分
        4.5.1.5 initialization部分
        4.5.1.6 finalization部分
    4.5.2 窗体单元
        4.5.2.1 命名
    4.5.3 数据模板单元
        4.5.3.1 命名
    4.5.4 一般目的单元
        4.5.4.1 命名
    4.5.5 构件单元
        4.5.5.1 命名
4.6 文件头
五、窗体和数据模板
5.1 窗体
    5.1.1 窗体类型命名标准
    5.1.2 窗体实例命名标准
    5.1.3 自动创建窗体
    5.1.4 模式窗体实例化函数
5.2 数据模板
    5.2.1 数据模板命名标准
    5.2.2 数据模板实例命名标准
六、包
6.1 使用运行包和设计包的比较
6.2 文件命名标准
七、构件
7.1 用户自定义构件
7.2 构件单元
7.3 使用注册单元
7.4 构件实例命名约定
7.5 构件的前缀
7.6  Standard        页
7.7  Additional      页
7.8  Win32           页
7.9  System          页
7.10 Internet        页
7.11 Data Access     页
7.12 Data Controls   页
7.13 Decision Cube   页
7.14 Qreport         页
7.15 Dialogs         页
7.16 Win3.1          页
7.17 Samples         页
7.18 ActiveX         页
7.19 Midas           页
7.20 ADO             页
7.21 InterBase       页
7.22 InternetExpress 页
7.23 FastNet         页

#31


UP

#32


最好不要用中文来命名,这样当语言环境变化以后,移植起来会遇到问题,很有可能出现乱码,e文到那个国家都不会出现问题,我们为什么不考虑远一些,不能埋下这些隐患 

to stwx()
(不用总是翻阅文档..)恐怖,居然有这样搞开发的!
(移植难除外..)我不知道这样重要的情况怎么能够除外!

况且查字典多学点单词也不是坏处
如果:
if ....then.....
变成
如果....那么.....        你会有什么感想?

最好的是建立术语表,建立一套规范,一套好的规范绝对可以解决你的3个问题
做程序不是画画,有的东西必须按照规范来。

#33


一个项目上来,最少也有几十个数据表,里面这么多的字段,你有不用查文档,都把所有字段都背下来?你能确定一看SQL语句知道它在做什么!使用中文命多,大家不要钻牛角尖,以方便,可读性为主! 如果觉得E文更方便,更可读,就使用E文,就像IF..Then,而不要拘泥于什么型式,要不就太迂腐了!

关于移植,重不重要,在于所开发的项目使用环境.至少,我还没有搞过要卖遍全球的产品.既然是国内的应用,只要确保在简体中文环境下没问题就可以了.
试问,现在有谁在使用E文的NT2000或SQL2000开发中文产品,毕竟很少吧!

#34


匈牙利命名法 是怎样的介绍一下

#35


天要下雨,娘要嫁人,有人就是爱用中文命名对象,随他去吧!
等那天他遇到单字节软件环境不认双字节变量的时候,看他找谁哭去!

另外,匈牙利等程序语言命名发对数据库对象命名意义不是太大,照老纳的规范命名就可以了!

#36


我们是这样定义的
表 xxxx_xxxxxxx_x
前三位是系统代号,比如cis  gis分别表示不同的应用。
第4为 是c ,m ,h c表示代码维护表一般是单表,m表示比较重要的表,h表示历史记录表.
中间那一段是表描述
最后一位是h d r,h表示主从表的主表,d表示主从表的从表,r表示联系表。

这种设计的好处,着眼于开发,是命名给程序员看的,看到这种表就知道套用哪种模板来开发。因此能提高开发速度,实践证明确实快不少!供大家参考

#37


缩写就DOS/TC 时代的产物,现在最好用全写

我就这么写,表直接写 Products, ProductTopCategories, ProductSubCategories ...

清楚明白的表达出意思就行了

#38


表:T 例如:TCustomer
存储过程:P 例如:PFetchCustomer、PDeleteCustomer
触发器:R 例如:RDeleteCustomer ON dbo.TCustomer FOR DELETE
视图:V 例如:VCustomer

#39


------------------------------------------------------------------------ 总体概述:返回符合指定查询条件的“教育背景”记录集。
----- 参数说明:nvarchar(1000) 可选参数,默认为指定的“集群编号”值,可含SQL的通配符。
-----   如果该参数为全空格字符串,则随机返回指定用户可读的第一条记录。注:该第一条记录是指物理存储位置,因此其结果是不可预知的;
-----   如果该参数为空值(NULL)或其它不存在的字段记录,则返回空记录集。
-----   该参数亦可是用户自定义的WHERE(不包含WHERE关键字)查询子句部分的SQL脚本,其必须是由左花括符“{” 与 右花括符“}”完全引用起来的一段字符串。
----- int 可选参数,指定的用户编号,省略该参数或该参数值为NULL,将忽略权限限制,否则只返回满足查询条件并符合流程权限定义的记录集。在基础资料部分该参数值保留。
----- 返回代码:int 整型数据类型,零:成功;非零:失败。
----- 结果集合:ClusterID uniqueidentifier 群集编号
----- SerialID int 记录序号
----- StartDate smalldatetime 起始日期
----- FinishDate smalldatetime 结束日期
----- Institute nvarchar(100) 受训学校
----- Profession nvarchar(100) 主修专业
----- Degree varchar(25) 学历
----- Remark nvarchar(255) 备注
----- 其它说明:钟峰·2002年09月06日 - 2002年09月06日(版本号:1.00)
-------------------------------------------------------------------

#40


关注!

#41


学习 

#42


mark一下

#43


支持英文命名,我在公司要求不允许用中文命名变量、表名、字段名,甚至程序里也不允许用汉字。因为中文命名现在在简体中文环境下你是爽了,可是要开发繁体版、英文版呢,恐怕重写还要简单点。

#44


用中文命名的还叫程序员吗?

#45


说说我通常的规则吧

表命名我绝不会加T或tbl前缀的
记得以前有人说过,如果你有几百个表
你就知道这样命名的痛苦了

我一般是加功能前缀,比如说bas_Customers pur_Vouch
视图,为了区分表,加vw_前缀,后面带上主要相关表名,再带上功能
存储过程,加pc_前缀,sp由于系统会首先查找master库,所以不推荐
触发器,tg_表名_功能 

字段命名,我还是喜欢类型简写+表简写+字段含义,
如cCusCode -- 客户编码,varchar型

具体SQL语句,关键字全部大写,除declare 和 数据类型

#46


再说一句,用拼音声母命名的话实际上比英文命名要难理解得多

不要考虑你去理解,而是别人去理解你的命名

#47


规范好

#48


好东东,收藏之!

#49


mk

#50


gz

#1


建议可以使用匈牙利命名法

#2


我使用的规则:
1。数据库:按实际用途取名,没有标准;
2。表:t_开头,加上英文名或缩写;
3。字段:具有一定意义的英文缩写;
4。视图:v_开头,加上英文名或缩写;
5。存储过程:p_开头,加上英文名或缩写;
仅供参考。

#3


happydreamer(绝对的黑):能否将匈牙利命名法将给大家,多谢。

#4


to happydreamer(绝对的黑):匈牙利命名法编程可以,但用在数据库就显得有些力不从心了,希望您具体一点

#5


我的规则:
tbl001, tbl002
其它类是,
然后建立说明文档文件,绝对清楚。

#6


我们公司在开发象分销系统、ERP这类管理软件的时候也跟: tj_dns(愉快的登山者)说的差不多
还有就是同一个模块的前缀最好一致,如库存管理模块 kcgl_XXXXXXX
基础数据:jcsj_XXXXX等等
这样清晰明了

#7


同志们,我要的是谁有标准文档啊,不是只举一个例子。

#8


我把我们公司的盗给你,呵呵

2 命名规则
2.1 表名
XXX相关表以r_作为前缀,YYY相关表以t_作为前缀。如r_acc 、t_bcc。
后台表名尽量与前台表名相同,后*有的表应以_b作为后缀。如r_gggd_b。
命名应尽量反映存储的数据内容。
2.2 视图名
视图以v_作为前缀。由于前台无视图,故不需加_b。
命名应尽量体现各视图的功能。
2.3 触发器名
触发器名为相应的表名加上后缀,Insert触发器加'_i',Delete触发器加'_d',Update触发器加'_u',如:r_bch_i,r_bch_d,r_bch_u。
2.4 存储过程名
存储过程应以'sp_'开头,后续部分主要以动宾形式构成,并用下划线分割各个组成部分。如增加BSC机架的DRT单板的存储过程为'sp_ins_board_drt'。
2.5 变量名
变量名采用小写,若属于词组形式,用下划线分隔每个单词,如@my_err_no。
2.6 命名中其他注意事项
以上命名都不得超过30个字符的系统限制。
变量名的长度限制为29(不包括标识字符@)。
数据对象、变量的命名都采用英文字符。禁止使用中文命名。
 
3 编程结构和描述
SQL SERVER系统中,一个批处理是从客户传给服务器的一个完整的包,可以包含若干条SQL语句。批处理中的语句是作为一组去进行语法分析、编译和执行的。触发器、存储过程等数据对象则是将批处理永久化的方法。
3.1 注释
注释可以包含在批处理中。在触发器、存储过程中包含描述性注释将大大增加文本的可读性和可维护性。本规范建议:
1、 注释以英文为主。
    实际应用中,发现以中文注释的SQL语句版本在英文环境中不可用。为避免后续版本执行过程中发生某些异常错误,建议使用英文注释。
2、 注释尽可能详细、全面。
创建每一数据对象前,应具体描述该对象的功能和用途。
传入参数的含义应该有所说明。如果取值范围确定,也应该一并说明。取值有特定含义的变量(如boolean类型变量),应给出每个值的含义。
3、 注释语法包含两种情况:单行注释、多行注释
单行注释:注释前有两个连字符(--),最后以行尾序列(CR-LF)结束。一般,对变量、条件子句可以采用该类注释。
多行注释:符号/*和*/之间的内容为注释内容。对某项完整的操作建议使用该类注释。
4、 注释简洁,同时应描述清晰。
3.2 函数注释:
编写函数文本--如触发器、存储过程以及其他数据对象--时,必须为每个函数增加适当注释。该注释以多行注释为主,主要结构如下:
/************************************************************************
*name        :               --函数名
*function    :               --函数功能
*input       :               --输入参数
*output      :               --输出参数
*author      :               --作者
*CreateDate  :              --创建时间
*UpdateDate  :               --函数更改信息(包括作者、时间、更改内容等)
*************************************************************************/
CREATE PROCEDURE sp_xxx

3.3 条件执行语句if…else
条件语句块(statenemt block,以 begin…end为边界)仅在if子句的条件为真时才被执行。为提高代码的可读性,建议嵌套不多于5层。还有,当嵌套层次太多时,应该考虑是否可以使用case语句。
3.4 重复执行while和跳转语句goto
需要多次执行的语句,可以使用while结构。其中,控制while循环的条件在任何处理开始之前需要先执行一次。循环体中的保留字break无条件的退出while循环,然后继续处理后续语句;保留字continue重新计算while条件,如果条件为真,则从循环开始处重新执行各语句。
使用跳转语句goto和标签label也可以方便地实现循环和其他更灵活的操作。SQL SERVER仅具有单通道语法分析器,因此不能解析对尚未创建的对象所做的前向参考。换言之,跳转到某标签的后续语句应该是可执行的(如不存在可能尚未创建的数据对象)。
3.5 书写格式
数据库服务器端的触发器和存储过程是一类特殊的文本,为方便开发和维护,提高代码的易读性和可维护性。规范建议按照分级缩进格式编写该文本。
顺序执行的各命令位于同一级;条件语句块(statenemt block,以 begin…end为边界)位于下一级,类推。
SQL语句是该文本的主体。为适应某些教复杂的用户需求,SQL语句可能比较庞大。为方便阅读和维护,规范建议按照SQL语句中系统保留字的关键程度再划分为三级。具体分级请参照下表。其中,非系统保留字(如字段名、数据表名、标点符号)相对本级保留字再缩进一级。多个连续的非保留字可以分行书写,也可以写在同一行。当WHERE包含的条件子句教复杂时,应该每行只写一个条件分句,并为重要的条件字句填写单行注释。
在保证基本缩进格式的前提下,可以通过对齐某些重要关键字(如条件关键字AND、OR,符号 = 、 <> 等)来进一步提高文本的易读性和可维护性。
相邻两级的缩进量为10个空格。这也是ISQL编辑器默认的文本缩进量。另外,在ISQL编辑器中,一个TAB键也相当于10个空格。

注:按照功能,四类SQL语句(SELECT、INSERT、UPDATE、DELETE)的关键字可以划分为三类:主关键字、次关键字、一般关键字。如下表所示:
主关键字 次关键字 一般关键字
SELECTINSERT (INTO)UPDATEDELETE  FROMWHEREVALUESINSERT…SELECT…FROM语句中的SELECT和FROM ANDORBETWEENINLIKE


3.6 字体
系统保留字应大写,包括系统公共变量等。其他字符(如用户自定义变量、用户自定义数据对象名)小写。
需要特殊强调的部分可以大写。
一条完整注释语句的首字符应大写。对某变量、某条件字句的注释可以全部使用小写。

通过下一节中生成表r_a的删除触发器的实例可以部分说明对象命名、注释、基本书写格式和字符大小写方面的一些注意事项。

4 触发器编程规范
4.1 范例
下面通过一个例子,说明触发器编程中应遵守的规范:

/* 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.2 事务过程中的触发器
1. 触发器内的rollback将所有工作返回至最外层的begin tran,完成触发器内的处理并异常终止当前的批处理。
2. 不可以从触发器内部返回至某个已命名的事务过程,这将产生运行错误,挂起所有工作并终止批处理。
5 存储过程编程规范
5.1 带有参数的执行
在执行存储过程时,可以通过名字来制定参数,这样可以用任何顺序传递参数,而且自动起到注释的作用,因此建议编程时使用这种方法。
5.2 缺省参数值
把参数的缺省值定为null,这是捕获在过程内调用存储过程所产生的错误的常用方法,不应让标准服务器消息报告参数丢失。在给定缺省之后,可以校验该缺省值并在存储过程内采取措施。
注意,当附值SELECT语句不返回行时,局部变量将保持在SELECT语句执行之前所具有的值。建议使用系统提供的某些全局变量(如@@ROWCOUNT)检测SELECT返回的结果。
5.3 返回值
每个存储过程自动返回一个整数型的状态值:成功完成时返回0,而返回-1~-99表示SQL Server检测到了错误。以下为SQL Server系统常用的返回状态码:
值 含义
    0 Procedure was executed successfully
  ?-1 Object missing
  ?-2 Datatype error occurred
  ?-3 Process was chosen as deadlock victim
 ? -4 Permission error occurred
  ?-5 Syntax error occurred
 ? -6 Miscellaneous user error occurred
  ?-7 Resource error, such as out of space, occurred
 ? -8 Non-fatal internal problem encountered
  ?-9 System limit was reached
??-10 Fatal internal inconsistency occurred
??-11 Fatal internal inconsistency occurred
??-12 Table or index is corrupt
??-13 Database is corrupt
  ?-14 Hardware error occurred
在程序中,用return语句可指定大于0或小于-99的返回值,调用程序可以设置局部变量接收和检查返回状态。
5.4 存储过程和事务处理
如果事务处理在存储过程返回时的嵌套层次与执行时的层次不同,SQL Server会显示信息提示事务处理嵌套失控。因为存储过程并不异常终止该批处理,在执行和确认随后的语句时,过程内的rollback tran 会导致数据完整性损失。
在编写存储过程时,应遵守以下原则:
1. 过程对@@trancount应无净改变。
2. 仅当存储过程发出begin tran语句时,才发出rollback tran。
5.5 其他注意事项
存储过程应该坚实可靠的,因为它们是驻留在服务器中,被频繁使用的。应仔细检查参数的有效性,并在有问题时返回出错信息。应确保参数的数据类型和被比较的栏的数据类型匹配,从而避免数据类型匹配错误。在每个SQL语句之后要检查@@error。

6 数据对象的国际化
6.1 关于数据对象的命名
数据对象和变量的命名一律采用英文字符。禁止使用中文命名。其他命名注意事项和规范请参考2命名规则。
6.2 关于RAISERROR
SQL SERVER 系统的RAISERROR命令能够把某个出错情况返回给调用过程,这对说明调用过程的执行情况很有必要;同时可以部分避免客户端的冗余操作。另外,结合系统存储过程sp_addmessage和sp_dropmessage可以方便实现数据对象在SQL SERVER端的国际化。
SQL SERVER的MASTER数据库中有错误信息数据表sysmessages,专门用于存储系

#9


to  sky_blue(老衲) :谢谢!谢谢!,不过文档开始的“XXX相关表以r_作为前缀,YYY相关表以t_作为前缀”,XXX,YYY什么意思,thanks

#10


XXX,YYY是我们产品的名字,我注掉了。呵呵

#11


后台表,前台表什么意思?thanks

#12


◆匈牙利命名法
匈牙利命名法是一名匈牙利程序员发明的,而且他在微软工作了多年。此命名法就是通过微软的各种产品和文档传出来的。多数有经验的程序员,不管他们用的是哪门儿语言,都或多或少在使用它

这种命名法的基本原则是:

变量名=属性+类型+对象描述

即一个变量名是由三部分信息组成,这样,程序员很容易理解变量的类型、用途,而且便于记忆。

下边是一些推荐使用的规则例子,你可以挑选使用,也可以根据个人喜好作些修改再用之。

⑴属性部分:

全局变量: g_

常量 : c_

类成员变量: m_

⑵类型部分:

指针: p

句柄: h

布尔型: b

浮点型: f 

无符号: u

⑶描述部分:

初始化: Init

临时变量: Tmp

目的对象: Dst

源对象: Src

窗口: Wnd 


下边举例说明:

hwnd: h表示句柄,wnd表示窗口,合起来为“窗口句柄”。

m_bFlag: m表示成员变量,b表示布尔,合起来为:“某个类的成员变量,布尔型,是一个状态标志”。

#13


匈牙利命名法
这个方法可能很多人都听说过,包括我在内的一些人也试图去使用它,可是还是觉得自己的好,但是现在看来这种想法是错误的。再解释解释吧。这些符号可以多个同时使用,顺序是先m_,(这上标记指成员变量)再指针,再简单数据类型,再其他。例如:m_lpszStr, 表示指向一个以0字符结尾的字符串的长指针成员变量。

a Array
b Boolean
by Byte
c Char //有符号型字符
cb Char Byte //无符号型字符(没多大用处)
cr ColorRef //颜色参考值
cx,cy Length of x,y (ShortInt) //坐标差(长度)
dw Double Word
fn Function
h Handle
i Integer
m_ Member of a class
n Short Integer
np Near Pointer
p Pointer lp Long Pointer
s String
sz String with Zero End //以字符'\0'结尾的字符串
tm Text //文本内容
w Word
x,y Coordinate //坐标

类名一般没有说明字符,例如theApp. 用在其他类中加m_就行。要注意的是:某些类也有类似于匈牙利命名法的缩写。例如:CStatusBar m_wndStatusBar;这里的wnd表示窗口类,但是这种命名法不是标准的匈牙利命名法的一部分。


http://www.longen.org/E-K/detaile~k/Hungary.htm

#14


来偷学:)

#15


UP

#16


I++先!谢谢各位!

#17


学习...

#18


来学习...小@_@小,今天刚刚换的名

#19


楼上的写的都是真好,我们公司居然用中文字符命名库,表。我利取说采用楼上的这几位高手的意见,却不采取,可悲。请问用中言语命名有什么优劣请给说明分析一下好吗?谢了。

#20


只有SB才会用中文命名数据库对象!

#21


谢谢 happydreamer(绝对的黑) 的匈牙利命名法,呵呵,还有我也是一个SB,因为我用中文命名表对象和字段对象

#22


我也赞成使用中文命名表名和字段名等,这样清晰易懂! 使用中文命名对系统并无什么影响,开发时也不需要总是翻阅说明文档,为何简单的事情不做,一定要读死书使用英文呢?

楼上用英文高手的能说说用中文弊端吗? 
(写程序切换输入法,移植难,的除外,重要说说对系统的影响!

#23


行有行规啦,自己看得清楚明白就可以啦

#24


个人认为匈牙利命名法用在C等开发语言中比较好,SQL中可以参考它但不必拘泥于它。毕竟数据库中的对象主要是表,视图,触发器,而不是int ,byte,array,指针之类。

#25


补充一点,对前面 sky_blue(老衲) 推荐的命名规范我比较欣赏,但同时由于其文中提出对Stored Procedure的命名加前缀'sp_'应有商榷的余地,因为master表中也有'sp_'开头的System Procedure,我在一本专业SQLServer书上看到,作者建议使用'up_'意为User Procedure,我以前也习惯用sp_命名自己的Stored Procedure不过现在为了规范,还是改为使用up_,当然个人也可以使用自己认为合适的前缀来命名.不过既然要走规范化编程道路,最好还是避免定义那些容易使别人产生混淆的名称.

另外使用中文命名数据库对象包括其他程序语言中变量名的朋友们,我前面说SB可能严重一点.我也不是什么权威并不能很好的给出中文命名就有什么弊端的解释,但是全世界的程序员都约定俗成以E文为标准程序语言的大环境下,不要把所谓有'中国特色'的逻辑带入程序设计的世界中来.

#26


个人认为,如果使用中文命名没有什么弊端,就应该从解决问题的方便性去考滤命名方式.为何一定要拘泥于一种所谓的标准,标准是外国人订的,肯定是以英文为主,谁教我们使用E文,书,书是哪来的,外国人写的,当然是E文标准了.

我们的目的是要能轻松方便的解决问题.整个系统在中文环境下应用,库结构非常清晰,不用总是翻阅说明文档.而且有时说明文档不一定能说明问题.况且,中文 NT2000与SQL2000内核都使用和允许使用中文.

我使用E文有如下问题:
1 可读性差. 看一条SQL语句不知道它在干什么.
2 表达的意思不清晰.如果以英文单词作表名和字段名,除非所有程序员都是英文高手,看得懂所有行业的术语,否则就可能要翻字典了.
3 按一定的规则命名,重名多.很多人使用拼音缩写,但如果有相似或相近的拼音,就会分不清楚,况且拼音有时也不一定读得很准.

所以,为我们为何简单的事情不做,非要搞得复杂才算是所谓的"标准"呢

#27


gz

#28


我有一篇这样的文档
不过主要是delphi方面的,希望能够对大家有所帮助:
太长了,大家慢慢看吧!

#29


Delphi 6 程序员代码编写标准指南

一、序言
二、通用源代码格式规则
2.1 缩格
2.2 页边空格
2.3 Begin…End 配对
2.4 代码文件中通用符号含义
三、Object Pascal
3.1 括号
3.2 保留字和关键字
3.3 过程和函数(例程)
    3.3.1 命名/格式化
    3.3.2 形式参数
        3.3.2.1 格式化
        3.3.2.2 命名
        3.3.2.3 参数的排序
        3.3.2.4 常量参数
        3.3.2.5 名称的冲突
3.4 变量
    3.4.1 变量的命名和格式
    3.4.2 局部变量
    3.4.3 全局变量的使用
3.5 类型
    3.5.1 大写约定
        3.5.1.1 浮点指针类型
        3.5.1.2 枚举类型
        3.5.1.3 变数和ole变数类型
    3.5.2 结构类型
        3.5.2.1 数组类型
        3.5.2.2 记录类型
3.6 语句
    3.6.1 if 语句
    3.6.2 case 语句
        3.6.2.1 一般性话题
        3.6.2.2 格式
    3.6.3 while 语句
    3.6.4 for 语句
    3.6.5 repeat 语句
    3.6.6 with  语句
        3.6.6.1 一般话题
        3.6.6.2 格式
3.7 结构异常处理
    3.7.1 一般话题
    3.7.2 try…finally的使用
    3.7.3 try…except的使用
    3.7.4 try…except…else的使用
3.8 类类型
    3.8.1 命名和格式
    3.8.2 域
        3.8.2.1 命名/格式
        3.8.2.2 可视化
    3.8.3 方法
        3.8.3.1 命名/格式
        3.8.3.2 使用静态的方法
        3.8.3.3 使用虚拟/动态的方法
        3.8.3.4 使用抽象的方法
        3.8.3.5 属性存取方法
    3.8.4 属性
        3.8.4.1 命名/格式
        3.8.4.2 使用存取的方法

#30


四、文件
4.1 工程文件
    4.1.1 命名
4.2 窗体文件
    4.2.1 命名
4.3 数据模板文件
    4.3.1 命名
4.4 远端数据模板文件
    4.4.1 命名
4.5 Unit文件
    4.5.1 通用Unit结构
        4.5.1.1 unit的名字
        4.5.1.2 uses子句
        4.5.1.3 interface部分
        4.5.1.4 implementation部分
        4.5.1.5 initialization部分
        4.5.1.6 finalization部分
    4.5.2 窗体单元
        4.5.2.1 命名
    4.5.3 数据模板单元
        4.5.3.1 命名
    4.5.4 一般目的单元
        4.5.4.1 命名
    4.5.5 构件单元
        4.5.5.1 命名
4.6 文件头
五、窗体和数据模板
5.1 窗体
    5.1.1 窗体类型命名标准
    5.1.2 窗体实例命名标准
    5.1.3 自动创建窗体
    5.1.4 模式窗体实例化函数
5.2 数据模板
    5.2.1 数据模板命名标准
    5.2.2 数据模板实例命名标准
六、包
6.1 使用运行包和设计包的比较
6.2 文件命名标准
七、构件
7.1 用户自定义构件
7.2 构件单元
7.3 使用注册单元
7.4 构件实例命名约定
7.5 构件的前缀
7.6  Standard        页
7.7  Additional      页
7.8  Win32           页
7.9  System          页
7.10 Internet        页
7.11 Data Access     页
7.12 Data Controls   页
7.13 Decision Cube   页
7.14 Qreport         页
7.15 Dialogs         页
7.16 Win3.1          页
7.17 Samples         页
7.18 ActiveX         页
7.19 Midas           页
7.20 ADO             页
7.21 InterBase       页
7.22 InternetExpress 页
7.23 FastNet         页

#31


UP

#32


最好不要用中文来命名,这样当语言环境变化以后,移植起来会遇到问题,很有可能出现乱码,e文到那个国家都不会出现问题,我们为什么不考虑远一些,不能埋下这些隐患 

to stwx()
(不用总是翻阅文档..)恐怖,居然有这样搞开发的!
(移植难除外..)我不知道这样重要的情况怎么能够除外!

况且查字典多学点单词也不是坏处
如果:
if ....then.....
变成
如果....那么.....        你会有什么感想?

最好的是建立术语表,建立一套规范,一套好的规范绝对可以解决你的3个问题
做程序不是画画,有的东西必须按照规范来。

#33


一个项目上来,最少也有几十个数据表,里面这么多的字段,你有不用查文档,都把所有字段都背下来?你能确定一看SQL语句知道它在做什么!使用中文命多,大家不要钻牛角尖,以方便,可读性为主! 如果觉得E文更方便,更可读,就使用E文,就像IF..Then,而不要拘泥于什么型式,要不就太迂腐了!

关于移植,重不重要,在于所开发的项目使用环境.至少,我还没有搞过要卖遍全球的产品.既然是国内的应用,只要确保在简体中文环境下没问题就可以了.
试问,现在有谁在使用E文的NT2000或SQL2000开发中文产品,毕竟很少吧!

#34


匈牙利命名法 是怎样的介绍一下

#35


天要下雨,娘要嫁人,有人就是爱用中文命名对象,随他去吧!
等那天他遇到单字节软件环境不认双字节变量的时候,看他找谁哭去!

另外,匈牙利等程序语言命名发对数据库对象命名意义不是太大,照老纳的规范命名就可以了!

#36


我们是这样定义的
表 xxxx_xxxxxxx_x
前三位是系统代号,比如cis  gis分别表示不同的应用。
第4为 是c ,m ,h c表示代码维护表一般是单表,m表示比较重要的表,h表示历史记录表.
中间那一段是表描述
最后一位是h d r,h表示主从表的主表,d表示主从表的从表,r表示联系表。

这种设计的好处,着眼于开发,是命名给程序员看的,看到这种表就知道套用哪种模板来开发。因此能提高开发速度,实践证明确实快不少!供大家参考

#37


缩写就DOS/TC 时代的产物,现在最好用全写

我就这么写,表直接写 Products, ProductTopCategories, ProductSubCategories ...

清楚明白的表达出意思就行了

#38


表:T 例如:TCustomer
存储过程:P 例如:PFetchCustomer、PDeleteCustomer
触发器:R 例如:RDeleteCustomer ON dbo.TCustomer FOR DELETE
视图:V 例如:VCustomer

#39


------------------------------------------------------------------------ 总体概述:返回符合指定查询条件的“教育背景”记录集。
----- 参数说明:nvarchar(1000) 可选参数,默认为指定的“集群编号”值,可含SQL的通配符。
-----   如果该参数为全空格字符串,则随机返回指定用户可读的第一条记录。注:该第一条记录是指物理存储位置,因此其结果是不可预知的;
-----   如果该参数为空值(NULL)或其它不存在的字段记录,则返回空记录集。
-----   该参数亦可是用户自定义的WHERE(不包含WHERE关键字)查询子句部分的SQL脚本,其必须是由左花括符“{” 与 右花括符“}”完全引用起来的一段字符串。
----- int 可选参数,指定的用户编号,省略该参数或该参数值为NULL,将忽略权限限制,否则只返回满足查询条件并符合流程权限定义的记录集。在基础资料部分该参数值保留。
----- 返回代码:int 整型数据类型,零:成功;非零:失败。
----- 结果集合:ClusterID uniqueidentifier 群集编号
----- SerialID int 记录序号
----- StartDate smalldatetime 起始日期
----- FinishDate smalldatetime 结束日期
----- Institute nvarchar(100) 受训学校
----- Profession nvarchar(100) 主修专业
----- Degree varchar(25) 学历
----- Remark nvarchar(255) 备注
----- 其它说明:钟峰·2002年09月06日 - 2002年09月06日(版本号:1.00)
-------------------------------------------------------------------

#40


关注!

#41


学习 

#42


mark一下

#43


支持英文命名,我在公司要求不允许用中文命名变量、表名、字段名,甚至程序里也不允许用汉字。因为中文命名现在在简体中文环境下你是爽了,可是要开发繁体版、英文版呢,恐怕重写还要简单点。

#44


用中文命名的还叫程序员吗?

#45


说说我通常的规则吧

表命名我绝不会加T或tbl前缀的
记得以前有人说过,如果你有几百个表
你就知道这样命名的痛苦了

我一般是加功能前缀,比如说bas_Customers pur_Vouch
视图,为了区分表,加vw_前缀,后面带上主要相关表名,再带上功能
存储过程,加pc_前缀,sp由于系统会首先查找master库,所以不推荐
触发器,tg_表名_功能 

字段命名,我还是喜欢类型简写+表简写+字段含义,
如cCusCode -- 客户编码,varchar型

具体SQL语句,关键字全部大写,除declare 和 数据类型

#46


再说一句,用拼音声母命名的话实际上比英文命名要难理解得多

不要考虑你去理解,而是别人去理解你的命名

#47


规范好

#48


好东东,收藏之!

#49


mk

#50


gz