请大家讨论一下数据库的设计规范？

数据库的设计有否规范？比如命名规范？或者大家认为如何做比较好？

Re: hi

[QUOTE][i]最初由 manplx 发布[/i]
[B]感觉这个问题已经讨论比较多了，例如《数据库的设计是一个项目的成败》等等。你认为呢？
[url]http://www.itpub.net/showthread.php?s=&threadid=1041[/url] [/B][/QUOTE]

我要说的是上面的讨论对具体应该如何设计讲得太少。我们公司现在数据库开发非常混乱，表名、字段名以及目录、文件等命名都不规范，每个人都有自己的一套，这是否该统一一下？

我觉得这个就是萝卜青菜各有所好。但是其中有一些规范以及个人经验不得不提。
我认为要设计数据库的时候列名和表名最好使用英文来表示（因为英文的意义大家可以明白字段的含义），但是缺点是需要了解各种数据库的关键字（如，我曾经见过很多人用date来做字段名，到写SQL语句的时候就麻烦大了），同时觉得使用汉字拼音也不好，因为如TABLE1_LSB你说是临时表还是历史表，说不清的。
         针对以上情况，我看到很多书上使用在表名前使用T_来表示，如T_TABLE1,T_TABLE2，用户存储过程用UP_来表示，,这样可以避免与关键字冲突。但是问题是写书的人没有什么实践经验（我就被这种书害过一回，使用了这种愚蠢的命名规范），当表的数量很多（如300个左右）再加上200来个存储过程，开发或管理时你需要找某个对象，如果你不使用什么T_，UP_打头，直接敲表的头一个字母就能定位到差不多的位置（如:MYTABLE只要敲入M就可以定位到以M打头的表），但是使用了T_ 后，真他妈难受，得一个个地找，因为都是T_打头。
        还有人建议把_T,_UP写在名字的后头，可是进行开发的时候也好不到哪里去，但是比什么T_ ，UP_好的多。
至于目录名和文件名，我也是使用英文来命名。所以现在我们开发的时候是这样的，先整理出标准SQL的关键字，再整理出Oracle,Sybase ASE ,MS SQL Server等比较流行的数据库的关键字，然后在命名的时候检查是否在建表的时候使用了这些关键字（你可以把这些关键字定义到PowerDesigner中，然后让它来替你检查)。
比较规范的命名看来只有等既有实践经验又有理论知识的人来整理出来。不知道谁见过比较标准的命名规范，告诉我一声，让我也按照这种规范来命名（因为我使用的规范在工作中发现还是繁！）。
         由于我被愚蠢的命名规范整过一回，所以现在我只要是看到什么教授的规范就来火，没有经验胡说八道什么，搞得开发的时候很多人都很恼火，把我扁的一文不值！

我做项目经理的时候定义的数据库命名规范

一．实体和属性的命名
1．        常用单词已经进行了缩写，在命名过程当中，根据语义拼凑缩写即可。注意，由于ORCAL数据库会将字段名称统一成大写或者小写中的一种，所以要求加上下划线
举例：
定义的缩写        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
6．        每一个表都将有一个自动ID作为主健,逻辑上的主健作为第一组候选主健来定义,如果是数据库自动生成的编码，统一命名为：ID;如果是自定义的逻辑上的编码则用缩写加“ID”的方法命名。
举例：销售订单的编号字段命名：Sal_Ord_ID；如果还存在一个数据库生成的自动编号，则命名为：ID。
7．        所有的属性加上有关类型的后缀，类型后缀的缩写定义见文件《类型后缀缩写定义》，注意，如果还需要其它的后缀，都放在类型后缀之前。
二．关系的命名
        关系的命名基本上按照;如有特殊情况,可以灵活处理．
        [must/may/can/should][verb/verb+prep][a/many/exatly num][or a/many]的结构命名
三．域的命名
四．触发器的命名
五．有关于默认的几点说明
1．        严格依赖关系的主细表，主表的后缀Main可以不写。
2．        数据类型是文本的字段，类型后缀TX可以不写。
3．        有些类型比较明显的字段，可以不写类型后缀。
4．        非常明显的关系,可以不写

确实是一种好的命名方法，并且能把数据库中的各种对象的类型描述的很清楚。能不能描述一下您在设计数据库中的各种对象分类如：实体类、冗余类、关联类等。您使用到的类型一共有多少种？
还有，能不能问一个问题。如在数据库设计的时候，每个实体都用一个ID来作为主关键字。但是如果此实体中的所有对象存在一个与其他对象不一致的唯一属性，那么可以从ID找到该条记录。也可以从它的唯一属性找到该条记录，这样的表结构会不会因为不符合第三范式而在使用的时候出现比较难预料的问题呢？

其实数据库的命名规范很简单

最好能采用习惯命名方法，否则就算你懂，小组其他人也不懂，小组其他人懂，拿给小组以外的人又不懂，就算大家都懂了，过几个月全忘了。再<<数据库设计>>一书中（好多其他的书也提到过）有数据库的命名规则，如果手头找不到书，打开数据库的范例教本总结一下就明白如何命名了。
用英文命名，太长的话就省掉元音，多单词的对象名称如果是表名或视图等就采用名次结构，存储过程采用动宾结构，所有对象均采用前缀+主题[+后缀] 的表示方法，设计的规范当然不仅仅是这些，也不仅仅是命名的规范，推荐<<数据库设计>>一书，虽然有点老，但很经典.

针对“所有对象均采用前缀+主题[+后缀] 的表示方法”，我想问一问。
你不会告诉我表名用T_,存储过程用UP_开头的吧？我不知道你设计和开发到有1900多个表的数据库没有？如果只有5个表，那这种命名无所谓，怎么也不会有任何问题，问题是对象多了。如，你从树形列表中在1900个以T_开始的表中找一个叫T_MYTABLE的表，一次两次还可以，每次都得不停地使用下拉滚动条，你会不觉得繁？我不相信！
还有，我觉得所有的标准应该是面向不同的数据库规模（不能一刀切），应该跟“设计模式”一样对不同的数据库设计体系、结构有不同的模式。

是哪一本《数据库设计》？

想问个问题，你们的主键都用自动编号的吗？
自动编号在数据恢复或者批量插入的时候总是有问题。所以我一般用自己生成的字串。

我觉得还是用中文比较好，至少大家都看的懂，当然在开发时还要加上表的关系图，不过设计的好不好，除了经验之外，有些规范也要用一用，但需灵活运用

对于字段命名我的体会：

字段数据类型缩写_字段英文缩写/中文缩写，缩写的规则一般项目组内必须一致，前提将字段含义表示清楚

这样的优点：更便于开发人员使用sql语句时，对于字段处理不容易出错！

如刚才的物品表的字段：
INT_Ma_ID//整型
VCH_Ma_Name//字符串
BL_Sign//布尔

我們公司的很不規范﹐每個人有一套﹒

我的原则：前缀+"_"+数据类型代码+字段名(中文拼音，前两个全拼，其它简拼)

当然有命名规范了 要不然别人怎么看你的代码？

嗯，规范还要有一定的延续性和继承性。