数据表命名和字段命名方法

在开发过程中,我采用多分节数据表命名方法(下划线命名法)。从实践来看,望文生义,维护效率很高,自己开发时,我很少看文档。 

一. 关于大小写

因为在编写软件过程中,会遇到很多语句会直接输入sql语句,所以应该作到全部表名,字段名小写。偶尔见到有的人把字段的开头用大写,但是在不区分大小的时候没问题,在区分大小写时,简直就是绊脚石。

我们可以看sql2000的master表。

二。命名方法

1. 表命名方法

主要分连写法和下划线两种方法。

连写法

如: sysindexkeys,sysfilegroups这适合于较小的数据运用项目,这样命名简短使用,编写sql语句时比较方便。但是在稍微复杂的按模组分类的系统中就显得力不从心了,因为涉及到多分层,连续拼写的英文会比较模糊。并且层次感不强。在强制小写的情况下,匈牙利命名法显得无奈。

在不区分大小写的情况下,骆驼式和pascal命名法失效了。这种方法不适合超过50张表的系统。

下划线法

这种方法我在使用中是按[模组]+[子模块]+[表名]+[附加项]

可以看出明显的层次结构。缺点就是比较长,但是你可以在分模块时,定义一些明确的缩写,来强制使用。

比如设计一个用户表,然后这个表还有多个外键表。我是如此命名的:

cust_info

cust_info_city(fk)   cust_info_area(fk)

cust_info_modified  cust_info_deleted  cust_info_stop

这里有个原则,就是主要的表尽量要短,因为使用频率很高。而Fk表我是用dw作成通用件,在需要的栏位用dddw方式展示。

这种方法适合系统不大,细化程度不高的情况。因为如果细化程度很高,在cust_info的层次上还会有多种细分层次(如cust_info_modified  cust_info_deleted ),所以命名就会增加到四节。就太长了。而且系统升级频繁的话,命名也存在歧义。比如cust_info_city(fk) 还有外键的话。(当然对于一些fk表,一般是char(2)+varchar(16),或者smallint+varchar(16),我们变通的做法是集中在一张表里,外加一个tabName字段来区分(tab+id+description)。然后在作fk的dw时,where条件里区分开不同表的FK即可(select id,description from fk_table where tab="tabname")。我认为是最好的方法。

当然我还见过正规的数据库,它没有采用这种字母的分节方法,而是采用模组+数字方式,但原则还是分节,只是更具有系统性。比如INV00100100101,字母在这里起到分模组的标识作用,而后面的数字分四节,而且前三层可以命名999个子模块,最后一节可以命名99张表。可以知道,这是大型系统采用的最好方法。在数据字典的强制作用下,设计和编写都会很规范。并且扩充容易。不容易混乱。对ERP系统等,是最好的方法。(最后的两位用于某表专署的外键或资源等)

这种方法适合table数量在300以上的系统,即使有1000张表也不存在任何问题。一般的ERP系统在500张表以上。是很复杂的,分模组,模块就显示必要。

对于procedure命名,同样实用。因为存储器存在系统存储器,所以首节最好区分开。我实用pr来分开(系统是sp_)。

2. 字段命名

2.1常规命名法

我的原则,尽量短,不用下划线。并且强制规范化。要缩短长度,必须考虑简写。如provider,customer,information,这些必须考虑全局强制统一简写法如:prv,cust,info。而对于常用的结构性描述词,则需全局通用化,比如userid,name,city,town,account,amount,type,class,area,country等。都是简短有用的,望文生义的词,不必要缩写。在不同的表里尽量强制统一。不要出现杂乱的局面。

字段名如果使用下划线,在编写sql语句时非常讨厌。因为表名尚且可以用别名,而字段名没法偷懒。

2.2. 丑陋的命名法

拼音命名法,数字命名法是很丑陋的。要杜绝

2.3.汉字命名法

在针对报表,导出数据临时表等非关键部分,可以采用汉字命名字段名,也是可以接受的。比如我在项目中有时设计到某个字段用汉字描述都很难理解,试想要用英文来命名更若天书,干脆就用了汉字命名。但是要遵守一下匈牙利方法,比如:客户代号,客户名称,客户地址,费用应收产成,费用应收折后。太随意跟拼音命名法就没区别了。

 
展开阅读全文

没有更多推荐了,返回首页