在开发过程中，我采用多分节数据表命名方法(下划线命名法）。从实践来看，望文生义，维护效率很高，自己开发时，我很少看文档。
一. 关于大小写
因为在编写软件过程中，会遇到很多语句会直接输入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.汉字命名法
在针对报表，导出数据临时表等非关键部分，可以采用汉字命名字段名，也是可以接受的。比如我在项目中有时设计到某个字段用汉字描述都很难理解，试想要用英文来命名更若天书，干脆就用了汉字命名。但是要遵守一下匈牙利方法，比如：客户代号，客户名称，客户地址，费用应收产成，费用应收折后。太随意跟拼音命名法就没区别了。
