关于数据库统一设计的个人体会

1、建模工具：推荐使用powerdesigner（简称pd）。建议所有的设计工作都在pd里面进行，然后通过pd直

接连到某个数据库的功能，直接运行pd生成的脚本。建议不要人为的在生成的具体数据库中做结构上的二

次修改，否则可能忽略掉在pd中做相应的修改，导致以后查看时出现某些表之间关系的不一致（据笔者经

验，表之间关系和实际数据库表关系的不一致在这种情况下显得相当严重）

2、表名的命名约定：建议一律用小写（oracle除外，因为oracle本身只支持大写），表名每个单词间用

统一的分隔符（建议用下划线）分隔。列名等其它对象的命名建议按照这种方式定义。这样做的好处，不

仅在阅读上方便，而且在其它工作，比如根据表名、列名生成对象以及对象的属性等方面，能够方便的定

义出相应的针对表名等的处理函数。

3、字符类型选择：字符型字段的类型，一般用varchar型，如果涉及中文的建议使用unicode编码的

nvarchar。相应的对于大数据类型的有text和ntext（sql server）。

4、字符类型长度选择：这个问题是笔者写这篇文章的主要驱动点。在笔者参与的数据库设计，以及从一

些有关数据库设计方面的书中，笔者未曾看到过这样的建议。也许这问题本身是相当的微不足道，但经过

笔者多次的亲身体验，还是觉得这个问题不可不提。原因主要有：大部分项目数据库设计不是由一个人设

计的，不同的人对字符型的长度定义都是凭当时的直觉的，这样必然导致不同的人设计出来的表结构基本

上是不同的（即使是同一张表，但由不同的人设计）。这本来问题不大，但假如第一个人设计了父表的某

个具有关联性质的字符型字段用varchar(20)（凭直觉），而第二个人在设计子表时对关联于父表的字符

型字段用varcahr(30)（甚至nvarchar(30)），这样的结果也许结构本身不会报错，但对于日后的查阅是

相当不便的。故笔者建议对字符型的字段以阶梯型来定义其长度，笔者比较喜欢用这样的阶梯型：10、50

、100、500、1000、2000、4000、5000、8000等。如此一来，表中的字符型字段的长度即便对于后来的设

计人员，也是可预知的

 

 

待续