今天放假，所以有时间再写一下

六）防止

一般的防止方法可分为跟风型和领先型

所为的跟风型，就是按着用别人的思路去找到问题所在，例如广告的特点、发布的方式、使用的是什么技术等。就看名称可能给人的感觉是有一点贬意，确实跟在人家后面走别人出什么怪招他就找出它的特征再来解决这个问题，这样子就是有好处的

　　　　优点：

　　　　１）改动小，每次修改的成本低

            ２）效果显示快

　　　　缺点：

　　　　１）长期运行成本高

　　　　２）容易产生漏动

　　　　３）有效期短

　所谓领先型，就是通过广告词的分析过滤，把一个内容综合成一个数值来确定它是不是一个垃圾信息，这种方法，可谓是一个领先的技术来了，包括了分词技术，数学原理、语言学等等多领域

　　　优点：

　　　１）长期运行成本低

　　　２）运行稳定

　　　缺点：

　　　１）开发成本高

　　　２）误报率高

　　　３）占用资源增多

（完）

现在网络上新兴起一群垃圾制造者，整天在制造垃圾，在浪费网络资源

二、意义

垃圾制造者与广告者的分别

这是我个人的想法：

广告者就是在网站上发布一些带有赢利为目的的服务或产品，所以在我的看法中，在自己的网站发布一些收费服务的人也是在做广告，只是在自己的网站上再通过internet来让别人知道

垃圾制造者就是制造很多相同或者相似的信息，并且在人家不愿意的情况下让人去看到你的信息，或者是网站不允许发布该内容的情况下发布

三、个人态度

对于一般的广告者，我是非分支持的，因为这样可以让交易更容易发生，让别人能找到他们想要的东西，（在一个网站的供求模块里发布自己的供求信息），这是件好事值得支持

但对于垃圾信息，我持清除态度，因为它浪费了资源

四、历史与现在情况

网站的经常有人在发布一些广告性质的信息，这一种情况一直存在。但以前没有现在的情况恶劣，因为以前由是由人手去发布信息所以发布的信息量不是太大，可现在不同了。因为现在有了好多群发软件，记得早几年就开始有那些群发邮件，当时我用邮件的次数不是太多所以没有什么感觉，邮件群发现在已经基本不会收到了，偶儿才会收到一两封，然后上年开始有那些QQ广告群发。

呵呵。。。。

刚开始几个月，基本上只要一上Q你就一定会收到那个广告信息，真得好烦，不过QQ的修正速度也很快，不到几个月，已经没有收到QQ广告群发的信息了

现在，基本上在一些使用通用论坛、CMS、及一些网站的程序时，都有专门的群发程序来完成大规模发布垃圾信息的工作。

五、情况总结

总结这三个群发信息的共同特征

1）由专门的工具来完成

2）可应用的时间越来越短

3）阻止方法都是找广告的特征并加以禁止

4）发布的地方都是人们常去看的地方（换句话来说就是有人的地方就有广告，有广告的地方就有垃圾）

六、防止

（现在已经很晚了，明天再写）

第一范式（1NF）：在关系模式R中的每一个具体关系r中，如果每个属性值 都是不可再分的最小数据单位，则称R是第一范式的关系。例：如职工号，姓名，电话号码组成一个表（一个人可能有一个办公室电话 和一个家里电话号码） 规范成为1NF有三种方法：
一是重复存储职工号和姓名。这样，关键字只能是电话号码。
二是职工号为关键字，电话号码分为单位电话和住宅电话两个属性
三是职工号为关键字，但强制每条记录只能有一个电话号码。
以上三个方法，第一种方法最不可取，按实际情况选取后两种情况。

第二范式（2NF）：如果关系模式R（U，F）中的所有非主属性都完全依赖于任意一个候选关键字，则称关系R 是属于第二范式的。
例：选课关系 SCI（SNO，CNO，GRADE，CREDIT）其中SNO为学号， CNO为课程号，GRADEGE 为成绩，CREDIT 为学分。 由以上条件，关键字为组合关键字（SNO，CNO）
在应用中使用以上关系模式有以下问题：
a.数据冗余，假设同一门课由40个学生选修，学分就 重复40次。
b.更新异常，若调整了某课程的学分，相应的元组CREDIT值都要更新，有可能会出现同一门课学分不同。
c.插入异常，如计划开新课，由于没人选修，没有学号关键字，只能等有人选修才能把课程和学分存入。
d.删除异常，若学生已经结业，从当前数据库删除选修记录。某些门课程新生尚未选修，则此门课程及学分记录无法保存。
原因：非关键字属性CREDIT仅函数依赖于CNO，也就是CREDIT部分依赖组合关键字（SNO，CNO）而不是完全依赖。
解决方法：分成两个关系模式 SC1（SNO，CNO，GRADE），C2（CNO，CREDIT）。新关系包括两个关系模式，它们之间通过SC1中的外关键字CNO相联系，需要时再进行自然联接，恢复了原来的关系

第三范式（3NF）：如果关系模式R（U，F）中的所有非主属性对任何候选关键字都不存在传递信赖，则称关系R是属于第三范式的。
例：如S1（SNO，SNAME，DNO，DNAME，LOCATION） 各属性分别代表学号，
姓名，所在系，系名称，系地址。
关键字SNO决定各个属性。由于是单个关键字，没有部分依赖的问题，肯定是2NF。但这关系肯定有大量的冗余，有关学生所在的几个属性DNO，DNAME，LOCATION将重复存储，插入，删除和修改时也将产生类似以上例的情况。
原因：关系中存在传递依赖造成的。即SNO -> DNO。 而DNO -> SNO却不存在，DNO -> LOCATION, 因此关键辽 SNO 对 LOCATION 函数决定是通过传递依赖 SNO -> LOCATION 实现的。也就是说，SNO不直接决定非主属性LOCATION。
解决目地：每个关系模式中不能留有传递依赖。
解决方法：分为两个关系 S（SNO，SNAME，DNO），D（DNO，DNAME，LOCATION）
注意：关系S中不能没有外关键字DNO。否则两个关系之间失去联系。

BCNF：如果关系模式R（U，F）的所有属性（包括主属性和非主属性）都不传递依赖于R的任何候选关键字，那么称关系R是属于BCNF的。或是关系模式R，如果每个决定因素都包含关键字（而不是被关键字所包含），则RCNF的关系模式。
例：配件管理关系模式 WPE（WNO，PNO，ENO，QNT）分别表仓库号，配件号，职工号，数量。有以下条件
a.一个仓库有多个职工。
b.一个职工仅在一个仓库工作。
c.每个仓库里一种型号的配件由专人负责，但一个人可以管理几种配件。
d.同一种型号的配件可以分放在几个仓库中。
分析：由以上得 PNO 不能确定QNT，由组合属性（WNO，PNO）来决定，存在函数依赖（WNO，PNO） -> ENO。由于每个仓库里的一种配件由专人负责，而一个人可以管理几种配件，所以有组合属性（WNO，PNO）才能确定负责人，有（WNO，PNO）-> ENO。因为 一个职工仅在一个仓库工作，有ENO -> WNO。由于每个仓库里的一种配件由专人负责，而一个职工仅在一个仓库工作，有 （ENO，PNO）-> QNT。
找一下候选关键字，因为（WNO，PNO） -> QNT，（WNO，PNO）-> ENO ，因此 （WNO，PNO）可以决定整个元组，是一个候选关键字。根据ENO->WNO，（ENO，PNO）->QNT，故（ENO，PNO）也能决定整个元组，为另一个候选关键字。属性ENO，WNO，PNO 均为主属性，只有一个非主属性QNT。它对任何一个候选关键字都是完全函数依赖的，并且是直接依赖，所以该关系模式是3NF。
分析一下主属性。因为ENO->WNO，主属性ENO是WNO的决定因素，但是它本身不是关键字，只是组合关键字的一部分。这就造成主属性WNO对另外一个候选关键字（ENO，PNO）的部 分依赖，因为（ENO，PNO）-> ENO但反过来不成立，而P->WNO，故（ENO，PNO）-> WNO 也是传递依赖。
虽然没有非主属性对候选关键辽的传递依赖，但存在主属性对候选关键字的传递依赖，同样也会带来麻烦。如一个新职工分配到仓库工作，但暂时处于实习阶段，没有独立负责对某些配件的管理任务。由于缺少关键字的一部分PNO而无法插入到该关系中去。又如某个人改成不管配件了去负责安全，则在删除配件的同时该职工也会被删除。
解决办法：分成管理EP（ENO，PNO，QNT），关键字是（ENO，PNO）工作EW（ENO，WNO）其关键字是ENO
缺点：分解后函数依赖的保持性较差。如此例中，由于分解,函数依赖（WNO，PNO）-> ENO 丢失了, 因而对原来的语义有所破坏。没有体现出每个仓库里一种部件由专人负责。有可能出现 一部件由两个人或两个以上的人来同时管理。因此，分解之后的关系模式降低了部分完整性约束。

一个关系分解成多个关系，要使得分解有意义，起码的要求是分解后不丢失原来的信息。这些信息不仅包括数据本身，而且包括由函数依赖所表示的数据之间的相互制约。进行分解的目标是达到更高一级的规范化程度，但是分解的同时必须考虑两个问题：无损联接性和保持函数依赖。有时往往不可能做到既有无损联接性，又完全保持函数依赖。需要根据需要进行权衡。

1NF直到BCNF的四种范式之间有如下关系：
BCNF包含了3NF包含2NF包含1NF

小结：
目地：规范化目的是使结构更合理，消除存储异常，使数据冗余尽量小，便于插入、删除和更新
原则：遵从概念单一化 "一事一地"原则，即一个关系模式描述一个实体或实体间的一种联系。规范的实质就是概念的单一化。
方法：将关系模式投影分解成两个或两个以上的关系模式。
要求：分解后的关系模式集合应当与原关系模式"等价"，即经过自然联接可以恢复原关系而不丢失信息，并保持属性间合理的联系。

注意：一个关系模式结这分解可以得到不同关系模式集合，也就是说分解方法不是唯一的。最小冗余的要求必须以分解后的数据库能够表达原来数据库所有信息为前提来实现。其根本目标是节省存储空间，避免数据不一致性，提高对关系的操作效率，同时满足应用需求。实际上，并不一定要求全部模式都达到BCNF不可。有时故意保留部分冗余可能更方便数据查询。尤其对于那些更新频度不高，查询频度极高的数据库系统更是如此。

在关系数据库中，除了函数依赖之外还有多值依赖，联接依赖的问题，从而提出了第四范式，第五范式等更高一级的规范化要求。在此，以后再谈。

各位朋友，你看过后有何感想，其实，任何一本数据库基础理论的书都会讲这些东西，考虑到很多网友是半途出家，来做数据库。特找一本书大抄特抄一把，各位有什么问题，也别问我了，自已去找一本关系数据库理论的书去看吧，说不定，对各位大有帮助。说是说以上是基础理论的东西，请大家想想，你在做数据库设计的时候有没有考虑过遵过以上几个范式呢，有没有在数据库设计做得不好之时，想一想，对比以上所讲，到底是违反了第几个范式呢？
我见过的数据库设计，很少有人做到很符合以上几个范式的，一般说来，第一范式大家都可以遵守，完全遵守第二第三范式的人很少了，遵守的人一定就是设计数据库的高手了，BCNF的范式出现机会较少，而且会破坏完整性，你可以在做设计之时不考虑它，当然在ORACLE中可通过触发器解决其缺点。以后我们共同做设计之时，也希望大家遵守以上几个范式。

    关键词：Oracle数据库 分区Partition 表空间Tablespace 数据文件Datafile

伴随着信息高速公路的飞速建设，油田的各项勘探开发数据都做到了及时准确入库，数据库中数据量日益增加。以其下属的某个采油厂为例，数据量已达到2GB，各种数据库表更是多达1千多个。与此同时，又产生了一个新问题，那就是虽然各种生产数据都已入库，但是由于数据量巨大，造成查询速度非常缓慢。

本文以油井日度数据表（dba01）为例进行说明。该表是最基础的开发数据，每天每一口井都有记录进入到数据库中。油田规定，该数据15个月内必须保存在线，15个月下来这个表就有997890条记录。

这接近100万条的记录大大增加系统开销，在用户提交查询后，经常需要等待五六分钟才能得到结果，有时甚至查不出数据，给用户的感觉是仿佛处于“死机”状态。

1 常规解决办法

解决大表查询速度缓慢的问题，最初的对策是在后台创建很多中间表。

例如：要得到采油厂生产日数据汇总情况屯解全厂每天的油井开井数、水井开井数、日产油量、注采比等重要数据，其缺点主要有两个：

（1）中间表的建立会占用大量表空间，即查询速度的提高是以牺牲服务器空间为代价，造成了巨大的资源浪费；

（2）随着各种应用的不断开展，中间表的数量也越来越多，这样人为加大了数据管理和维护的工作量。

因此，要从根本上解决大表存在的查询速度缓慢的问题，必须找到更为有效的方法。

2 采用分区功能解决问题

（1）分区的定义

分区将表分离在若干不同的表空间上，将大的表和索引拆分成小的易于管理的数据片段，分而治之支撑无限膨胀的大表，给大表物理一级的可管理性。将大表分割成较小的分区可以改善表的维护、备份、恢复、事务及查询性能。针对我厂大量的油水井日度数据，可以推荐使用Oracle9的分区功能。

（2）分区的优点

首先，能够成倍提高查询速度：分区管理后，服务器可以进行智能的分区检测。跳过与查询无关的分区访问，并跳过不在线的分区。

其次，增强系统可用性：如果表的一个分区由于系统故障而不能使用，其余好的分区仍然可能使用。

不同分区可以跨表空间存储，降低了磁盘损坏带来的数据不可用性。

3 分区的管理

（1）建立表的各个分区的表空间

下面是建立2004年第一季度表空间的操作语句，指定所建立表空间的名字，所用数据文件的名称、大小和存放目录，并由存储字句指定在该空间中所建立对象的缺省存储参数。

CREATE TABLESPACE ts_dba01_2004q1

DATAFILE '/home2/oracle/test/dba01/2004q1.SIZE 200MB

DEFAULT STORAGE (INITIAL 30m NEXT 30m)

MINEXTENTS 3 PCTINCREASE 0);

(2)建立分区表

下面是建立dba01表的操作语句，指定表名、列名及列的数据类型等。这些都与常规创建表的语句相同。

CREATE TABLE dba01

(jh varchar2(16)not null,

rq date not null,

cyfs varchar2(3),

dwdm varchar2(11),

……

PARTITION BY RANGE(rq)

PARTITION dba01_2003q4

VALUES LESS THAN(TO_DATE('2004-01-01','YYYY-MM-DD')

TABLESDPACE ts_dba01_2003q4,

PARTITION dba01_2004q1

VALUES LESS THAN(TO_DATE('2004-04-01','YYYY-MM-DD')

TABLESPACE ts_dba01_2004q1)

这是创建分区的语句，指定指照日期进行分区，例如：

日期>='2004-01-01'并且<'2004-04-01'（即2004年第一季度）的数据放在dba01_2004q1分区内。其他分区也依此原则建立。

（3）分区表的扩充

在2004年年底，向表中加入2005年的表空间，同样是每季度一个表空间，预计每个分区为200MB。下面是创建2005年第一季度表空间的操作语句，指定表空间名称、数据文件名称及大小等。

CREATE TABLESPACE ts_dba01_2005q1

DATAFILE '/home2/oracle/dba01_2005q1.dat'SIZE

200MB

DEFAULT STORAGE (INITIAL 40m NEXT40m)

MINEXTENTS 3 PCTINCREASE 0）

其他季度表空间也如此建立。

（4）为表添加表空间

操作语句如下：

ALTER TABLE dba01

ADD PARTITION dba01_2005q1

VALUES LESS THAN(TO_DATE('2005-04-01','YYYY-MM-DD')

TABLESPACE ts_dba01_2005q1;

（5）删除不必要的分区

采油厂规定：必须保存15个月的日度数据在线。到2005年，必须把2003年3季度的数据备份，将该分区删除，腾出空间供后续数据循环使用。删除分区ALTER TABLE dba01 DROP PARTION dba01_2003q3;

利用操作系统工具删除这个分区所占用的文件

oracle$ rm /home2/oracle/test/dba01_2003q3.dat

（6）查看分区信息

可通过对数据字典USER_EXTENTS进行查询，操作如下：

SVRMGRL>SELECT *FROM user_extents

WHERE SEGMENT_NAME='dba01';

（7）卸载分区

Oracle9的EXPORT工具可卸载分区并导出数据，例如到2002年，可将2000年的数据按分区卸载。

例如：要卸载2003年3季度的数据，数据如下：

oracle$ exp tycx/***

tables=dba01:dba01_2003d3 file=dba01_2003q3.dmp

在语句中要指定用户名、口令、需要卸出的表名及分区名、卸出文件名称等。

（8）导入分区

Oracle9的IMPORT工具可导入分区并加载数据，例如在2005年，用户要查看2003年的数据，必须导入该年数据。

·建立该表2003年的四个表空间和相应的分区；

·下面是导入2003年3季度分区数据的操作语句：

oracle$ imp tycx/***

file=dba01_2003q3.dmp tables=(dba01:dba01_2003q3)

4 实验效果

（1）能够成倍提高查询速度

分区管理后，服务器可以进行智能的分区检测，跳过与查询无关的分区访问，跳过不在线的分区。

（2）增强系统可用性

如果表的一个分区由于系统故障而不能使用，其余好的分区仍然可以使用。

不同分区可以跨表空间存储，降低了磁盘损坏带来的数据不可用性。

以油井日数据表为例：

不采用分区技术时，若表空间文件受到破坏，会影响到所有数据都无法使用，必须将该表全部记录（多达100万条）重新恢复，工作量很大，恢复期间用户根本无法查询数据，完全不能使用。

而采用分区技术后，由于整个表已按季度拆分为6个分区，因此当某一个表空间文件被破坏，则仅是该分区表空间所对应的季度数据无法使用，其他季度数据仍然可以正常使用，对用户的查询以及其他应用影响不大。

通过合理应用Oracle9的分区功能，可以大大改善系统的性能，降低大表数据管理和维护的工作量，对大表的查询、增加、修改等操作可以分解到表的不同分区并行执行，可使运行速度更快。对促进无纸化办公，辅助生产有积极的推动作用。

]]> https://atim.cn/post/51/ bkkkd <partybase@gmail.com> Sat, 18 Feb 2006 02:33:23 +0000 https://atim.cn/post/51/ 在开始做http://133.newsky.cn之前，我已经明白网站的开发与产品开发没有什么不同。不过在2004年离开微软中国研发中心Office组的时候，我对网站开发仍一无所知，这主要是因为我之前没有任何互联网研发的背景。虽然对传统软件产品的研发管理比较有经验，但从未接触过Internet相关的项目。

从零开始与网站开发亲密接触

去年我接手第一个网站项目http://www.okooo.com开发时，并没有做网站的经验，只能试着按照以前我参与做Microsoft Office时的方法来做：

首先是打造一个便于公司内部沟通交流的内部网，其中包含“传统软件”研发需要的三个工具：文档库（存放公司各项目的文档）、CVS（保存项目的各种源代码）、BugFree（记录项目的各种缺陷）；

然后，抓住“需求、开发、测试”三个环节：

l         要做好规划、明确需求。为什么要做这个网站、要达到什么目标？特别是需求，要详细到每个页面的每个区域放置什么内容。网站需求应该由对业务最熟悉的人来定义，他负责按照我要求的规范（详细程度）来写出每一部分需求文档，并放入文档库中。每完成一个页面定义，我就召集开发、测试人员来阅读、讨论，这样全部需求写完的时候，项目组成员对整个网站就有了一个清晰的认识。

l         需求明确才进入开发阶段。首先是定义数据库——有多少张表、每张表中有多少个字段。我和开发组长反复讨论，搞清楚这些表定义能否涵盖全部需求，这是最关键的一步，决定着下面编码能否顺利进行。数据库定义后，就是网站后台管理的编码实现，也就是对一张张表进行管理（增、删、改）。当后台管理完成时，项目的大部分就大功告成了。用户看到的前台页面仅仅是内容展示——把一张张表中的数据取出来按照最初的需求放置到页面的各个位置。所有的代码都用CVS管理起来。

l         网站测试和开发同步进行。后台管理每完成若干张表的管理，测试人员立即开始测试。这就像流水线，开发完一部分，立刻测试；同样的，网站前台展示开发时也一样需要测试人员跟进。发现的每一个Bug都用BugFree记录下来跟踪处理过程。

l         数据统计跟上。网站后台各个表的任何改动要准确记录，决不允许出现不知道谁修改了数据库内容的情况。其次，网友访问网站的日志要做好统计，每天结束的时候就能准确的看到当天的用户访问数据。这些数据对网站运营极其重要。

四个月后，我的第一个网站项目顺利上线。所有参与该项目的同事感觉都很新鲜，因为以前他们在做网站时，基本上是一个人“包干”一个频道，简单构思一下就开始写程序、边写边想、相互独立。后来，我跟一位曾在某门户网站工作过的高级工程师朋友介绍了上面的做法，他非常认同和赞赏，得到他的认可我也很兴奋。

随后接触到的很多网站技术人员，让我发觉作坊式做法同样存在于互联网公司，网站在重复多年前传统软件的老路：一个“大虾”很厉害，搞定一个频道或一个网站的方方面面，离开他谁都玩不转；代码中处处留着他的灵感，人走了，网站维护就成了大难题：没有文档、没有统一的编码规范、没有测试记录。

其实无论传统软件、网站、还是游戏等等软件产品/项目，都是程序员用一行行代码敲出来的，只要像微软软件研发那样抓住需求、开发、测试这三个环节，其管理都极其类似。因此当我进入http://133.newsky.cn网站项目的时候，信心十足：我能把它管好！

打造一个网站开发的品牌项目

05年2月18日：项目启动，开始整体规划

在我加入金环天朗的时候，这个网站就已经存在了，而最开始的计划也只是对原有的网站进行局部改版。但是等我深入了解后，大吃一惊：

u       规划／需求：原有网站没有经过认真规划就匆忙上马，只有部分的简单示意图，对于每个页面具体区域的功能描述和逻辑过程还是依赖口头沟通。没有独立的后台管理，依赖于WAP业务的后台，内容展示力不从心。

u       页面设计：美工因为还有其它工作所以有一定程度的拖延，没有时间观念，整个设计方案没有经过整体评估，导致后来许多细节没有按照计划实现，页面设计先后由两人分头独立完成，导致部分风格不一致。

u       开发：技术实现一直处在救火的状态，没有规划，没有步骤，没有主次之分，没有时间观念。代码的结构非常散乱，没有可用的文档查询，开发人员走了，给以后接手的人带来极大的麻烦。代码没有规范、没有注释。归结起来就是可读性很差。

u       测试：没有任何测试，开发人员简单试一试就直接上线了！

u       内容：网站内容维护没有专人负责，逐渐处于无人答理的状态。

总之，原来的网站有太多不尽人意之处，和同类网站比起来差距较大，市场人员无法推广，技术人员很难维护，动不动就出错。只能另起炉灶，推倒重做一个全新的网站。

对一家SP公司而言，做网站是打通让用户消费的通道。从常远看，内容为王，但短期内通道为王：就是让用户很容易找到公司提供的内容。因为WAP业务非常依赖于运营商的门户排名，一个业务放在运营商WAP门户上，第一屏和第二屏有着本质的不同，愿意翻到第2屏上的用户可能少一半或更多！所以SP要想尽一切办法来摆脱对门户的唯一依赖，必须能用别的通道让用户很方便的找到你的业务。而网站就是最好的宣传通道，是公司产品最重要的展示平台。网站研发的目标就是尽快打通联通、移动用户的消费通道，把公司生产出来的产品（图、铃、文字）方便地展示给更多的手机用户。

这个http://133.newsky.cn网站是面向中国联通用户的，其设计目标是：

?         1~3年内不需要改动大框架

?         公司业务内容的精美展示、销售平台

?         在同行中有很强的竞争力

?         老板可以拿出来给投资人演示

为了达成这个设计目标，我和项目组花了近一个月的时间来制定完整规划。

明确的研发流程应该是一个开发团队的固定资产，从这点上，我建立了一套项目研发流程，并为其提供工具支撑：

?         认识老网站的现状、确定新网站的设计目标；对新网站的总体设计图纸进行反复讨论，确定网站研发的四个总原则（灵活的后台、以专题为网站细胞、丰富的资讯、翔实的内容）；明确人员分工、并预告项目执行的几个关键点。

?         在没有公司内部网的情况下，我先搭建两个工具：用于保存各种文档和源代码的TortoiseCVS(客户端)+CVS(服务器端)，用于缺陷管理的BugFree。为每个项目搭建一个CVS模块，其中都有四个子目录：Spec(需求文档)、Design(设计文档)、Code(源代码)、Test(测试文档)。

示意图：网站项目的CVS目录

然后是人力资源，我在规划中提出了非常明确的人力资源需求：

?         前台需求定义：1人（蔡志宏）

?         后台需求定义：2人（刘振飞、朱伟波）

?         美工设计制作：1人

?         开发：3人

?         测试：5人

?         运营：5人

然而，当时的情况却是项目组人员迟迟无法到位：美工只有一个兼职的、时间无法保证；只有一个开发组长；没有测试人员；网站运营人员不能确定。针对这样的情况，我的任务还包括了招聘相关人员及时到位。

在整体上完成上述工作以后，时间已经是3月22日了，事实上，在整个项目启动初期的准备阶段是一个非常重要的工作，清晰的项目规划也为后来的工作扫清了很多障碍。这就是俗话说的“磨刀不误砍柴工”。

05年3月22日：开始定义网站需求

网站需求特别难以确定，为了解决这个问题，我将整个需求定义划分为三个主要的部分：

1．网站前台展示的定义

我首先和负责定义需求的蔡志宏确定了需求Spec文档模板，然后他根据首页、二级、三级页面逐个页面、逐个模块的去定义：展示什么内容，大概的模样（最终样式由美工负责）。这样每个页面都被分解成一块块的“部件”，一个“部件”由一份Spec描述，比如下面是“首页公告栏区域需求定义”Spec的示意图。

示意图：首页公告栏区域的需求定义Spec

每完成若干相关联的Spec，我就召集美工、开发人员开会讨论（本应该也叫上测试和运营人员，但当时还没有人），大家站在不同的角度去看看有无问题，并最终确认下来。

2．联通用户消费流程的定义

用户消费流程涉及到收费问题，必须把每个细节都要搞清楚。这个需求由我负责，先形成一份PPT文档，在大范围内征求大家的意见，然后细化每个细节：从用户访问我们的首页开始，如何登录，如何转向联通网站，如何扣费等每个细节必须想到。

3．网站后台管理的定义

       根据网站前台的需求，我和开发组长朱伟波来设计数据库定义，确定多少张表、每张表中有什么字段。然后从运营人员的登录页面开始设计，用PPT把每张页面的示意图以及逻辑关系都展示出来，然后把需求、开发、美工召集起来一起讨论，看看是否符合运营人员的习惯、是否有遗漏的地方。

需求文档要想清楚后再写下来，让别人读得懂。定义好的需求Spec是整个项目开发的“合同”，马虎不得。在需求定义的3周中（其中前台展示的需求用了2周、后台管理的需求用了1周），每写出来若干相关的需求文档，就在项目组内讨论一次，最终明确下来。需求文档一旦成型以后，就必须严格按照需求文档编写设计代码，尽量控制需求的变化。这不但要求我们在最开始的需求分析阶段做好最充分的准备工作，而且还需要作为项目经理的我，顶住一些来自各方意见的压力。幸运的，我们团队还是非常好的坚持下来了：

示意图：上线后的首页公告栏区域——完全根据Spec中的需求定义来实现

然而，另外的一个问题是，需求文档很容易“老旧”、跟不上最新的变化，需求定义人也懒得去更新，因为开始编码后谁都不去注意需求文档了。为了解决这个问题，我就在后台管理的每一张表的维护页面上，增加一个“Spec”按钮，点击后就可以看到相关的需求文档Spec列表了。这样做有两个好处：一方面运营人员可以很方便的看到最初是怎么设计这块功能的；另一方面也把需求定义者的工作暴露在全体同事面前，文档写的好坏是一目了然。

充分的需求定义保证了整个项目能够准时完工，这也是我们这个项目能够取得圆满成功的原因之一。需求确定之后，后面开发、测试的时间就基本明确下来了。

05年4月12日：数据库设计，正式编码开发

有了完整的需求文档后，接下来就进入开发阶段。如同前面提及的，首先需要完成的是数据库的设计。其实早在需求定义期间，我和朱伟波就已经开始数据库定义，确定多少张表、每张表中有什么字段。我们花费了三天左右的时间来对后台数据库进行详细的设计，并产生出设计文档。

示意图：新天地网站2005版后台数据库定义.doc

然而，光有需求和详细设计文档还不够，开发团队需要保持要一种一致的风格，这一点要求所有的程序员对代码有责任感。因此在这个阶段之前（3/16~4/12），我就让公司所有的Java工程师多次讨论，并最后确定一份“编码规范”，这样网站真正开始写代码的时候，就有一个明确的规范来约束代码的书写。

对于软件项目来说，经常会有一些出乎意料的情况发生。比如，本来计划有两个开发人员做后台管理，结果因为沈阳联通的一个合作项目需求紧急配合，只好临时抽调一个人去支援，毕竟网站是公司内部可以控制的，导致后台开发只有朱伟波一个“光杆司令”，那一段他连续十余天加班到晚上11:30！这样高强度、高压力的工作状态，不是每个程序员都能承受的。经过朱伟波的努力，终于在十天时间内将所有的后台编码全部完成（4月16日至4月26日）。

紧接下来，从5月10日开始，专门为网站开发配备的两个Java程序员到位，朱伟波首先给他们介绍后台管理和Struts技术。随后分工：首页、3个铃声二级、3个图片二级、杂志、热门推荐、精彩专题等，每人承担几个频道的实现，分头阅读对应的需求文档并随时找蔡志宏讨论不清楚的地方。当理解需求之后，由朱伟波协调，三个人分头开始进行前台展示页面的编码工作，加班加点，在5月31日基本结束。

05年4月28日：与开发并行的测试

在这个项目之前，整个公司是没有测试人员的！这不得不让我大为惊讶，一个SP公司没有测试怎么行！所以在这个项目进行的同时我启动测试人员招聘工作，最终成立了一支5人组成的测试组，负责所有业务的测试。

当网站后台管理编码完成后，4/28立即启动测试工作：后台管理中的首页管理、动画、声音、彩图、专题、资讯由专人负责测试，发现一个问题就在BugFree中记录一个Bug。通过BugFree的跟踪和记录，可以让某些问题不必累积到最后才解决。随着网站前台展示开发在5月中旬启动，测试工作也在并行跟进：每个频道、每个页面都有专人负责检查，这样尽可能的把各种潜在的问题揪出来，免除后患。

示意图：用BugFree来管理网站项目中的Bug

很遗憾的是，因为测试组搭建的比较晚、测试任务又比较重，他们需要花费很长时间去熟悉公司的各种业务，所以在这个网站项目中，对测试文档部分（比如测试用例）我并没有要求，只要把问题发现出来上Bug就好了。这就是项目管理中的Trade-Off：抓住主要矛盾、抓大放小。这个项目结束后，测试组已经逐步成熟、磨合好了，我才开始强调测试文档的重要性，每个业务测试时一定要同步完成相关的测试文档（计划、用例、测试结果等），测试时就按照相关的测试文档进行。这样以后复测就能省掉很多时间，换个人测试也很方便上手。

经过一个多月的努力，测试组的同事基本上完成了网站所有频道、页面的检查工作（6月8日）。

05年5月23日：迟到的运营组开始运转

研发人员做出来的网站只是一个空空的框架，没有实际的内容填上去，网站就无法上线——打个比方，研发人员把“大楼”盖好了，还需要运营人员把“内部装修”做好。然而面对人员的稀缺和内部调整，一直到5月23日才确定运营组长及组员分工，他们匆匆进入角色，一面熟悉网站后台管理，一面准备内容。6月8日才开始正式的网站内容录入。

在此期间，整个项目组都进入了最后的冲刺阶段。为了确保6月15日网站能够上线，我开始将工作日往后倒推，每一周甚至每一天，需求、美工、开发、测试、运营等环节需要到达什么状态，必须做到心中有数；每天都要盯着进度，一旦有了延误，必须立即找到原因和补救方法。如果实在忙不过来，我就要做出决定砍掉哪些可以延缓的功能模块。

示意图：项目最后突击的日志

05年6月15日：网站正式上线！

值得庆祝的日子到来了。6月15日凌晨我正式向全公司同事报告这个网站正式上线。这是我自己主持研发的第二个网站，也是我非常用心管理的一个项目。我想留下一个参考样板，为公司其他项目的管理摸索经验。我认为这是一个成功的项目是因为：

整个项目组成员在网站上线后都非常兴奋，这应该是公司到目前最成功的一个项目管理实践。公司领导对这个项目的研发表示非常满意。现在的情况是，休整2周后，7月4日按计划我们又启动了第2步移动网站的研发；另外对历史遗留的众多WAP业务的整理开始提上议事日程。我需要更多时间、耐心和细心，和需求、开发、测试等各个环节的同事们密切配合，把公司各个业务的项目都理出头绪来、让研发部为公司业务的不断成长做出贡献，也让技术人员工作“累身不累心”，不要总是“救火”，要能看到辛苦工作的成效。

网站和产品开发没有什么不同！

按我整理的时间表和项目计划，对照微软的流程，你会发现，我完全是按照微软“传统软件”的研发流程去管理这个网站项目，略有不同的地方是，这个网站项目的时间跨度比较小（只有4个月），而且人力资源有限，美工、开发、测试三个环节我只能是并行处理、流水作业，以尽量缩短项目的整体时间。

我也算是“把微软先进的软件研发理念和中国中小企业的具体情况相结合”吧，其中最难的是把项目研发流程的理念灌输给全组同事以统一认识，并能有效的执行下去。很多时候要靠我不断的去PUSH各个环节，做的比较累，但在完成之后，很有成就感，尤其是针对一个团队不断发展和成熟，所做的努力是显而易见的。（未完待续）

2.RUP就是“杂物箱”
      我也许总是在批评RUP，但是不得不承认它是对前人在软件过程思想方面的高度包容。请注意我用“包容”这个词，而不是按照语言习惯那样用“概括”。因为如果是“高度概括”，那就应该把目光投向瀑布模型，而RUP其实就像一个杂物箱一样“包容”了全部的已知理论。
      可以把RUP定制成其它任何模型所表述的过程形态——RUP本身的特质决定了这一点——因而它也如同一个杂物箱一样放满了各种希奇古怪的东西：你可能从这个杂物箱里面拿出了一把剪刀，或一只苍蝇拍，或者是一根钓杆……
      面对“软件开发”这样的需求，钓杆能有什么作用呢？在你扔掉它之前，请转换一下思维：钓杆可能带给你的团队以精神上的激励。如果你能意识到这一点，那么它将立即转化为生产力——请把钓杆挂在开发部的墙上。
      RUP能不能被用起来，将取决于你刚才那个挑挑捡捡的行为，以及在你拿到“钓杆”后的辨识能力与组织能力。

3.UML与甲骨文之间的异同
      在你真的打算用“甲骨文”来写项目文档之前，请先弄明白UML与甲骨文之间的异同。在本书里，它们都被做为沟通的工具。因此，目标是沟通，而不是“选用工具”。更进一步的推论是：即使你因为个人喜好而选择了甲骨文，也不要试图在结绳记事的原始人面前去用它。UML与甲骨文都是符号文字，都具有像形含义。然而，这并不表明UML符号本身能表达多么丰富的含义。如果要像甲骨文一样用几代人、上千册的论著去解释它，那么UML图的价值也就只剩下象征性意义了。
      出于沟通的必要，UML语言的象征意义在一个图中应当被表述得足够准确和详细，以致对于不同的阅读者来说都提供了充足的信息。然而，一方面UML的规范中没有提供一个标准来衡量“怎样的UML图是描述充分的”；另一方面，UML作为一个语言，也无法直接在某个硬件平台中被语法检错和调试。所以在工程中使用UML图，应该有相应的文字来描述它。而且，这种描述与图之间的对应关系要持续地维护下去。如果这种关系松散了、断裂了，那么下一个阅读UML图的人所面对的将是无异于甲骨文出土时的困境。好在做UML图的那个工程设计人员(在辞世之前)还有机会为这些古怪符号写下规约。

4.经营者离开发者很远，反之亦然
      使我第一次意识到EHM模型反应了角色所关注的不同视角的人，是我的老板。
事实上，他是一个完全不懂软件技术的老板。在EHM模型中，他所处于的位置在最右端，而开发者在最左端，在二者之间没有相同的关注界面(关注点)。EHM真实地反应了“老板不懂技术”的合理性，同样也真实地反应了“开发者转型为老板”的道路将是相当地漫长与艰难。
      于是，担任中间角色的项目经理就有了一种使命：协调经营者与开发者之间的沟通。例如招来一名开发高手，对于公司的运作并不会有深入的影响(当然，如果你招来了Anders Hejlsberg就另当别论)。因此，我甚至不需要与BOSS讨论这名高手的来历及作用。同样，与一个技术分析人员讨论一个产品的技术价值、市场价值之间的差异，以及市场运作方式与技术实现手段的无关性是毫无必要的。
你要理解这种根源：角色的关注层面完全不同。

5.矛盾：实现目标与保障质量
      在需求阶段我们会面临“目标”的问题,然而在大多数时候，与此相反的是我们会在项目交付和试用时才会碰到客户在质量上的投诉。
      需求人员会把所有的责任归咎到开发人员，而开发人员又不停地埋怨需求的不清不楚或者变更的没完没了。如果正巧需求和开发都是由同一个人或者同一小组来做的，那么他们便会开始埋怨客户的苛刻以及工期的紧张。
总之一件事，没有人会跳出来说：我们原本就错了。然而，事实上根本问题可能是：我们把目标定错了。
      可以看到，在项目的平衡三角(时间、资源和功能)中讨论的是目标问题，但并不讨论质量问题。也就是说，经典教材中总是关注如何更快的完成项目，并减少资源占用，以及实现更多的功能。但是，即使平衡了这种关系，项目的结果仍可能产生一个天生的残障。因为目标可能在平衡中确立，但质量却要在过程中控制。即使在时间、资源和功能三者中取得了平衡，并且客户、项目组和公司同样满意于这个平衡“目标”，但它仍然有可能是“不能实施”的。
      如果原定的目标本身就过大，那么无论如何平衡这三者之间的关系，其结果仍旧是保障不了质量。
      问题是：又有谁愿意在最初签订协议的时候，就降低或者放弃协议标准呢？

6.枝节与细节
      前面说到目标和质量的问题时，提及“平衡时间、资源和功能三者的关系”。这其实是一个实施过程中的细节。或者说，它是一个具体的方法，而不是目的。
      所以我们通常所说的细节，其实是对实施方法的一些有限量的描绘。比如“软件工艺”概念本身的提出，就是考究“细节问题”的。从这个角度上来说，我并不反对“细节决定成败”的观点。但请注意一个前提：这是技术或方法的细部。
      我在前文中一再地混用了“细节”与“枝节”这两个词。枝节是事实发展的次要的分枝，它不涉及行为本身，也不是对行为本身的考量。因此我在前面的文字中说到“跳出细节”，本意是“跳出枝节”——细节只有做到何种程度的问题，而并不是关不关注(或做不做)的问题。
大多数情况下，管理人员有责任去审核、评估其它成员的工作成果。这个时候可以讨论“细节决定成败”类似的问题，因为这决定了产品的最终质量，而质量是工程的目标之一。
      而在另一些情况下，例如管理人员做事件决策的时候，就必须要学会忽略枝节问题。
      混淆这两个名词的使用，其根本原因在于一大部分读者并不能区分“细节”与“枝节”。从惯于“实做”的程序员一路走来的工程人员，很难分清自己什么时候是在“工作”，而什么时候是在“决策”。
      因此我只好用最笨的方法提示管理者：别管它是细节还是枝节，只要你感到你的脚趾已经沾上了泥淖，就快点回头。
      用脚趾去感觉，有时比用头脑去思维来得有效。

7.灵活的软件工程
      并不像现代人想象的那样，古诗词一定是“逐字论平仄”的。变化或者变通，其实是常见之事。因此古词谱中，才常会见到冠以“摊破”、“减字”、“添字”等字的词格。然而古人在词格上的这种变通，是基于“音律”的。通常说的词律是指词格，这与音律是两回事。词律(格)是平仄，音律则是乐器、音调与歌舞。古词中用来吟唱与歌舞的词牌就不能混用，律不同，调不同，如是之。然而古词的音律(亦即是律谱)已经失传了，也就是说，今天的词是用来读的，不是唱，也不是舞，甚至连吟哦也不是。所以今人总是拿普通话中的一、二声作为平声，三、四声为仄声来填词，并以此论平仄，而全然不想词的格律的根基是“词律”与“音律”这两个部分的融合。
      我曾经参与过一个讨论，叫“古人是如何说话的”。在我看来，古人做文章和说话是两回事，文章中之乎者也，日常交流中还是市井俚语的。因此评论中会说“以俚语入词”。也可见填词做文章与说话毕竟是不同。再者，说话也存在方言的问题，因此方言之间平仄音调也不尽相同。古代的歌妓是要求会“官话”的，这相当于现在“普通话”的地位，她们歌唱起来，也是用的“官话”。
      更进一步的推论是：古代的词律中的平仄是以官话为基础的。然而如今的普通话毕竟不是古时的“官话”。也就是说，即使我们以普通话的四声为基础讨论平仄，在古人看来，也是可笑的，这样做出来的词依旧不可唱，也不可读。因此今人做词的标准是应该重定的了，除了词格(这里仅指字句的格式)和用韵之外，其它的部分是无法遵循的了。在各自的平仄以及句式上，应当以“能通顺”和“能品味”为准，风格上则以古雅为益。
      仅此而已。
      对于我这样的格律观点，一位网友曾有一句“未蕴而变，自欺也；知律而变，智者之道也”，实为良言。变向不变求。不变者，万变之所源，亦万变之所归。习诗词之法度，若蚕虫之结茧，若无结茧于前，何有破茧于后？故，知律而变，智者之道也。
      “知律而变”中的“律”字，若解释为“规律”，便是可以用于软件工程中了。“道”是规律，如果明“道”，而可以变化无穷，这样做软件工程才是活的。就如同今人难于填词一样，不明道，则不明智，不明智则无所以为，因而在软件工程实施中不可避免地盲目与停滞。
      “知律”的另一层意思，是在于“知道原理”。明白“为什么要这样”或者“为什么不是那样”。这在软件开发中是常见的问题，大多数人不知究竟地使用着技巧和方法，而一旦出了问题，则归咎于这些技巧和方法的不好。而真正的问题在于，这些人(我们通常叫做Copy&Paster)并不知道这些技巧、技术和方法的原理，因而不知道变通，也不知道回避错误。
      死读一本《软件工程》的人不会做真正的软件工程，所以我写了本书，聊做软件工程实践者的思想之著。

一
个成功的管理系统，是由：[50% 的业务 + 50% 的软件] 所组成，而 50% 的成功软件又有 [25% 的数据库 + 25% 的程序]
所组成，数据库设计的好坏是一个关键。如果把企业的数据比做生命所必需的血液，那么数据库的设计就是应用中最重要的一部分。有关数据库设计的材料汗牛充
栋，大学学位课程里也有专门的讲述。不过，就如我们反复强调的那样，再好的老师也比不过经验的教诲。所以我归纳历年来所走的弯路及体会，并在网上找了些对
数据库设计颇有造诣的专业人士给大家传授一些设计数据库的技巧和经验。精选了其中的 60
个最佳技巧，并把这些技巧编写成了本文，为了方便索引其内容划分为 5 个部分：

第 1 部分 - 设计数据库之前
这一部分罗列了 12 个基本技巧，包括命名规范和明确业务需求等。
第 2 部分 - 设计数据库表
总共 24 个指南性技巧，涵盖表内字段设计以及应该避免的常见问题等。
第 3 部分 - 选择键
怎么选择键呢？这里有 10 个技巧专门涉及系统生成的主键的正确用法，还有何 时以及如何索引字段以获得最佳性能等。
第 4 部分 - 保证数据完整性
讨论如何保持数据库的清晰和健壮，如何把有害数据降低到最小程度。
第 5 部分 - 各种小技巧
不包括在以上 4 个部分中的其他技巧，五花八门，有了它们希望你的数据库开发工作会更轻松一些。
第 1 部分 - 设计数据库之前
考察现有环境
在
设计一个新数据库时，你不但应该仔细研究业务需求而且还要考察现有的系统。大多数数据库项目都不是从头开始建立的；通常，机构内总会存在用来满足特定需求
的现有系统（可能没有实现自动计算）。显然，现有系统并不完美，否则你就不必再建立新系统了。但是对旧系统的研究可以让你发现一些可能会忽略的细微问题。
一般来说，考察现有系统对你绝对有好处。
定义标准的对象命名规范
一定要定义数据库对象的命名规范。对数据库表来说，从项目一开始就要
确定表名是采用复数还是单数形式。此外还要给表的别名定义简单规则（比方说，如果表名是一个单词，别名就取单词的前 4
个字母；如果表名是两个单词，就各取两个单词的前两个字母组成 4 个字母长的别名；如果表的名字由 3
个单词组成，你不妨从头两个单词中各取一个然后从最后一个单词中再取出两个字母，结果还是组成 4
字母长的别名，其余依次类推）对工作用表来说，表名可以加上前缀 WORK_
后面附上采用该表的应用程序的名字。表内的列[字段]要针对键采用一整套设计规则。比如，如果键是数字类型，你可以用 _N
作为后缀；如果是字符类型则可以采用 _C
后缀。对列[字段]名应该采用标准的前缀和后缀。再如，假如你的表里有好多“money”字段，你不妨给每个列[字段]增加一个 _M
后缀。还有，日期列[字段]最好以 D_ 作为名字打头。

检查表名、报表名和查询名之间的命名规范。你可能会很快就被这些不同的数据库要素的名称搞糊涂了。假如你坚持统一地命名这些数据库的不同组成部分，至少你应该在这些对象名字的开头用 Table、Query 或者 Report 等前缀加以区别。

如
果采用了 Microsoft Access，你可以用 qry、rpt、tbl 和 mod 等符号来标识对象（比如
tbl_Employees）。我在和 SQL Server 打交道的时候还用过 tbl 来索引表，但我用 sp_company （现在用
sp_feft_）标识存储过程，因为在有的时候如果我发现了更好的处理办法往往会保存好几个拷贝。我在实现 SQL Server 2000 时用
udf_ （或者类似的标记）标识我编写的函数。
工欲善其事, 必先利其器
采用理想的数据库设计工具，比如：SyBase 公司的
PowerDesign，她支持 PB、VB、Delphe 等语言，通过 ODBC 可以连接市面上流行的 30 多个数据库，包括
dBase、FoxPro、VFP、SQL Server 等，今后有机会我将着重介绍 PowerDesign 的使用。
获取数据模式资源手册
正
在寻求示例模式的人可以阅读《数据模式资源手册》一书，该书由 Len Silverston、W. H. Inmon 和 Kent
Graziano
编写，是一本值得拥有的最佳数据建模图书。该书包括的章节涵盖多种数据领域，比如人员、机构和工作效能等。其他的你还可以参考：[1]萨师煊　王珊著　数
据库系统概论(第二版)高等教育出版社 1991、[2][美] Steven M.Bobrowski 著 Oracle 7
与客户／服务器计算技术从入门到精通　刘建元等译　电子工业出版社，1996、[3]周中元　信息系统建模方法(下)　电子与信息化　1999年第3期，
1999
畅想未来，但不可忘了过去的教训
我发现询问用户如何看待未来需求变化非常有用。这样做可以达到两个目的：首先，你可以清楚地了解应用设计在哪个地方应该更具灵活性以及如何避免性能瓶颈；其次，你知道发生事先没有确定的需求变更时用户将和你一样感到吃惊。

一定要记住过去的经验教训！我们开发人员还应该通过分享自己的体会和经验互相帮助。即使用户认为他们再也不需要什么支持了，我们也应该对他们进行这方面的教育，我们都曾经面临过这样的时刻“当初要是这么做了该多好..”。
在物理实践之前进行逻辑设计
在深入物理设计之前要先进行逻辑设计。随着大量的 CASE 工具不断涌现出来，你的设计也可以达到相当高的逻辑水准，你通常可以从整体上更好地了解数据库设计所需要的方方面面。
了解你的业务
在你百分百地确定系统从客户角度满足其需求之前不要在你的 ER（实体关系）模式中加入哪怕一个数据表（怎么，你还没有模式？那请你参看技巧 9）。了解你的企业业务可以在以后的开发阶段节约大量的时间。一旦你明确了业务需求，你就可以自己做出许多决策了。

一旦你认为你已经明确了业务内容，你最好同客户进行一次系统的交流。采用客户的术语并且向他们解释你所想到的和你所听到的。同时还应该用可能、将会和必须等词汇表达出系统的关系基数。这样你就可以让你的客户纠正你自己的理解然后做好下一步的 ER 设计。
创建数据字典和 ER 图表
一
定要花点时间创建 ER 图表和数据字典。其中至少应该包含每个字段的数据类型和在每个表内的主外键。创建 ER
图表和数据字典确实有点费时但对其他开发人员要了解整个设计却是完全必要的。越早创建越能有助于避免今后面临的可能混乱，从而可以让任何了解数据库的人都
明确如何从数据库中获得数据。

有一份诸如 ER 图表等最新文档其重要性如何强调都不过分，这对表明表之间关系很有用，而数据字典则说明了每个字段的用途以及任何可能存在的别名。对 SQL 表达式的文档化来说这是完全必要的。
创建模式
一张图表胜过千言万语：开发人员不仅要阅读和实现它，而且还要用它来帮助自己和用户对话。模式有助于提高协作效能，这样在先期的数据库设计中几乎不可能出现大的问题。模式不必弄的很复杂；甚至可以简单到手写在一张纸上就可以了。只是要保证其上的逻辑关系今后能产生效益。
从输入输出下手
在
定义数据库表和字段需求（输入）时，首先应检查现有的或者已经设计出的报表、查询和视图（输出）以决定为了支持这些输出哪些是必要的表和字段。举个简单的
例子：假如客户需要一个报表按照邮政编码排序、分段和求和，你要保证其中包括了单独的邮政编码字段而不要把邮政编码糅进地址字段里。
报表技巧
要
了解用户通常是如何报告数据的：批处理还是在线提交报表？时间间隔是每天、每周、每月、每个季度还是每年？如果需要的话还可以考虑创建总结表。系统生成的
主键在报表中很难管理。用户在具有系统生成主键的表内用副键进行检索往往会返回许多重复数据。这样的检索性能比较低而且容易引起混乱。
理解客户需求
看
起来这应该是显而易见的事，但需求就是来自客户（这里要从内部和外部客户的角度考虑）。不要依赖用户写下来的需求，真正的需求在客户的脑袋里。你要让客户
解释其需求，而且随着开发的继续，还要经常询问客户保证其需求仍然在开发的目的之中。一个不变的真理是：“只有我看见了我才知道我想要的是什么”必然会导
致大量的返工，因为数据库没有达到客户从来没有写下来的需求标准。而更糟的是你对他们需求的解释只属于你自己，而且可能是完全错误的。
第 2 部分 - 设计表和字段
检查各种变化
我
在设计数据库的时候会考虑到哪些数据字段将来可能会发生变更。比方说，姓氏就是如此（注意是西方人的姓氏，比如女性结婚后从夫姓等）。所以，在建立系统存
储客户信息时，我倾向于在单独的一个数据表里存储姓氏字段，而且还附加起始日和终止日等字段，这样就可以跟踪这一数据条目的变化。
采用有意义的字段名
有一回我参加开发过一个项目，其中有从其他程序员那里继承的程序，那个程序员喜欢用屏幕上显示数据指示用语命名字段，这也不赖，但不幸的是，她还喜欢用一些奇怪的命名法，其命名采用了匈牙利命名和控制序号的组合形式，比如 cbo1、txt2、txt2_b 等等。
除非你在使用只面向你的缩写字段名的系统，否则请尽可能地把字段描述的清楚些。当然，也别做过头了，比如 Customer_Shipping_Address_Street_Line_1，虽然很富有说明性，但没人愿意键入这么长的名字，具体尺度就在你的把握中。
采用前缀命名
如果多个表里有好多同一类型的字段（比如 FirstName），你不妨用特定表的前缀（比如 CusLastName）来帮助你标识字段。

时效性数据应包括“最近更新日期/时间”字段。时间标记对查找数据问题的原因、按日期重新处理/重载数据和清除旧数据特别有用。
标准化和数据驱动
数
据的标准化不仅方便了自己而且也方便了其他人。比方说，假如你的用户界面要访问外部数据源（文件、XML
文档、其他数据库等），你不妨把相应的连接和路径信息存储在用户界面支持表里。还有，如果用户界面执行工作流之类的任务（发送邮件、打印信笺、修改记录状
态等），那么产生工作流的数据也可以存放在数据库里。预先安排总需要付出努力，但如果这些过程采用数据驱动而非硬编码的方式，那么策略变更和维护都会方便
得多。事实上，如果过程是数据驱动的，你就可以把相当大的责任推给用户，由用户来维护自己的工作流过程。
标准化不能过头
对那些不熟悉
标准化一词（normalization）的人而言，标准化可以保证表内的字段都是最基础的要素，而这一措施有助于消除数据库中的数据冗余。标准化有好几
种形式，但 Third Normal Form（3NF）通常被认为在性能、扩展性和数据完整性方面达到了最好平衡。简单来说，3NF 规定：
* 表内的每一个值都只能被表达一次。
* 表内的每一行都应该被唯一的标识（有唯一键）。
* 表内不应该存储依赖于其他键的非键信息。
遵
守 3NF 标准的数据库具有以下特点：有一组表专门存放通过键连接起来的关联数据。比方说，某个存放客户及其有关定单的 3NF
数据库就可能有两个表：Customer 和 Order。Order 表不包含定单关联客户的任何信息，但表内会存放一个键值，该键指向
Customer 表里包含该客户信息的那一行。
更高层次的标准化也有，但更标准是否就一定更好呢？答案是不一定。事实上，对某些项目来说，甚至就连 3NF 都可能给数据库引入太高的复杂性。

为
了效率的缘故，对表不进行标准化有时也是必要的，这样的例子很多。曾经有个开发餐饮分析软件的活就是用非标准化表把查询时间从平均 40
秒降低到了两秒左右。虽然我不得不这么做，但我绝不把数据表的非标准化当作当然的设计理念。而具体的操作不过是一种派生。所以如果表出了问题重新产生非标
准化的表是完全可能的。
Microsoft Visual FoxPro 报表技巧
如果你正在使用 Microsoft
Visual FoxPro，你可以用对用户友好的字段名来代替编号的名称：比如用 Customer Name 代替
txtCNaM。这样，当你用向导程序 [Wizards，台湾人称为‘精灵’] 创建表单和报表时，其名字会让那些不是程序员的人更容易阅读。
不活跃或者不采用的指示符
增
加一个字段表示所在记录是否在业务中不再活跃挺有用的。不管是客户、员工还是其他什么人，这样做都能有助于再运行查询的时候过滤活跃或者不活跃状态。同时
还消除了新用户在采用数据时所面临的一些问题，比如，某些记录可能不再为他们所用，再删除的时候可以起到一定的防范作用。
使用角色实体定义属于某类别的列[字段]
在需要对属于特定类别或者具有特定角色的事物做定义时，可以用角色实体来创建特定的时间关联关系，从而可以实现自我文档化。
这
里的含义不是让 PERSON 实体带有 Title 字段，而是说，为什么不用 PERSON 实体和 PERSON_TYPE
实体来描述人员呢？比方说，当 John Smith, Engineer 提升为 John Smith, Director 乃至最后爬到
John Smith, CIO 的高位，而所有你要做的不过是改变两个表 PERSON 和 PERSON_TYPE
之间关系的键值，同时增加一个日期/时间字段来知道变化是何时发生的。这样，你的 PERSON_TYPE 表就包含了所有 PERSON
的可能类型，比如 Associate、Engineer、Director、CIO 或者 CEO 等。
还有个替代办法就是改变 PERSON 记录来反映新头衔的变化，不过这样一来在时间上无法跟踪个人所处位置的具体时间。
采用常用实体命名机构数据
组
织数据的最简单办法就是采用常用名字，比如：PERSON、ORGANIZATION、ADDRESS 和 PHONE
等等。当你把这些常用的一般名字组合起来或者创建特定的相应副实体时，你就得到了自己用的特殊版本。开始的时候采用一般术语的主要原因在于所有的具体用户
都能对抽象事物具体化。
有了这些抽象表示，你就可以在第 2 级标识中采用自己的特殊名称，比如，PERSON 可能是
Employee、Spouse、Patient、Client、Customer、Vendor 或者 Teacher
等。同样的，ORGANIZATION 也可能是
MyCompany、MyDepartment、Competitor、Hospital、Warehouse、Government 等。最后
ADDRESS 可以具体为 Site、Location、Home、Work、Client、Vendor、Corporate 和
FieldOffice 等。
采用一般抽象术语来标识“事物”的类别可以让你在关联数据以满足业务要求方面获得巨大的灵活性，同时这样做还可以显著降低数据存储所需的冗余量。
用户来自世界各地
在设计用到网络或者具有其他国际特性的数据库时，一定要记住大多数国家都有不同的字段格式，比如邮政编码等，有些国家，比如新西兰就没有邮政编码一说。
数据重复需要采用分立的数据表
如果你发现自己在重复输入数据，请创建新表和新的关系。
每个表中都应该添加的 3 个有用的字段
* dRecordCreationDate，在 VB 下默认是 Now()，而在 SQL Server 下默认为 GETDATE()
* sRecordCreator，在 SQL Server 下默认为 NOT NULL DEFAULT USER
* nRecordVersion，记录的版本标记；有助于准确说明记录中出现 null 数据或者丢失数据的原因
对地址和电话采用多个字段
描述街道地址就短短一行记录是不够的。Address_Line1、Address_Line2 和 Address_Line3 可以提供更大的灵活性。还有，电话号码和邮件地址最好拥有自己的数据表，其间具有自身的类型和标记类别。

过分标准化可要小心，这样做可能会导致性能上出现问题。虽然地址和电话表分离通常可以达到最佳状态，但是如果需要经常访问这类信息，或许在其父表中存放“首选”信息（比如 Customer 等）更为妥当些。非标准化和加速访问之间的妥协是有一定意义的。
使用多个名称字段
我觉得很吃惊，许多人在数据库里就给 name 留一个字段。我觉得只有刚入门的开发人员才会这么做，但实际上网上这种做法非常普遍。我建议应该把姓氏和名字当作两个字段来处理，然后在查询的时候再把他们组合起来。

我最常用的是在同一表中创建一个计算列[字段]，通过它可以自动地连接标准化后的字段，这样数据变动的时候它也跟着变。不过，这样做在采用建模软件时得很机灵才行。总之，采用连接字段的方式可以有效的隔离用户应用和开发人员界面。
提防大小写混用的对象名和特殊字符
过
去最令我恼火的事情之一就是数据库里有大小写混用的对象名，比如 CustomerData。这一问题从 Access 到 Oracle
数据库都存在。我不喜欢采用这种大小写混用的对象命名方法，结果还不得不手工修改名字。想想看，这种数据库/应用程序能混到采用更强大数据库的那一天吗？
采用全部大写而且包含下划符的名字具有更好的可读性（CUSTOMER_DATA），绝对不要在对象名的字符之间留空格。
小心保留词
要
保证你的字段名没有和保留词、数据库系统或者常用访问方法冲突，比如，最近我编写的一个 ODBC 连接程序里有个表，其中就用了 DESC
作为说明字段名。后果可想而知！DESC 是 DESCENDING 缩写后的保留词。表里的一个 SELECT *
语句倒是能用，但我得到的却是一大堆毫无用处的信息。
保持字段名和类型的一致性
在命名字段并为其指定数据类型的时候一定要保证一致
性。假如字段在某个表中叫做“agreement_number”，你就别在另一个表里把名字改成“ref1”。假如数据类型在一个表里是整数，那在另一
个表里可就别变成字符型了。记住，你干完自己的活了，其他人还要用你的数据库呢。
仔细选择数字类型
在 SQL 中使用 smallint 和 tinyint 类型要特别小心，比如，假如你想看看月销售总额，你的总额字段类型是 smallint，那么，如果总额超过了 $32,767 你就不能进行计算操作了。
删除标记
在表中包含一个“删除标记”字段，这样就可以把行标记为删除。在关系数据库里不要单独删除某一行；最好采用清除数据程序而且要仔细维护索引整体性。
避免使用触发器
触发器的功能通常可以用其他方式实现。在调试程序时触发器可能成为干扰。假如你确实需要采用触发器，你最好集中对它文档化。
包含版本机制
建
议你在数据库中引入版本控制机制来确定使用中的数据库的版本。无论如何你都要实现这一要求。时间一长，用户的需求总是会改变的。最终可能会要求修改数据库
结构。虽然你可以通过检查新字段或者索引来确定数据库结构的版本，但我发现把版本信息直接存放到数据库中不更为方便吗？。
给文本字段留足余量
ID
类型的文本字段，比如客户 ID
或定单号等等都应该设置得比一般想象更大，因为时间不长你多半就会因为要添加额外的字符而难堪不已。比方说，假设你的客户 ID 为 10
位数长。那你应该把数据库表字段的长度设为 12 或者 13 个字符长。这算浪费空间吗？是有一点，但也没你想象的那么多：一个字段加长 3
个字符在有 1 百万条记录，再加上一点索引的情况下才不过让整个数据库多占据 3MB
的空间。但这额外占据的空间却无需将来重构整个数据库就可以实现数据库规模的增长了。身份证的号码从 15 位变成 18 位就是最好和最惨痛的例子。

列[字段]命名技巧
我们发现，假如你给每个表的列[字段]名都采用统一的前缀，那么在编写 SQL
表达式的时候会得到大大的简化。这样做也确实有缺点，比如破坏了自动表连接工具的作用，后者把公共列[字段]名同某些数据库联系起来，不过就连这些工具有
时不也连接错误嘛。举个简单的例子，假设有两个表：
Customer 和 Order。Customer 表的前缀是 cu_，所以该表内的子段名如下：cu_name_id、cu_surname、cu_initials 和cu_address 等。Order 表的前缀是 or_，所以子段名是：
or_order_id、or_cust_name_id、or_quantity 和 or_description 等。
这样从数据库中选出全部数据的 SQL 语句可以写成如下所示：
Select * From Customer, Order Where cu_surname = "MYNAME" ;
and cu_name_id = or_cust_name_id and or_quantity = 1
在没有这些前缀的情况下则写成这个样子（用别名来区分）：
Select * From Customer, Order Where Customer.surname = "MYNAME" ;
and Customer.name_id = Order.cust_name_id and Order.quantity = 1
第 1 个 SQL 语句没少键入多少字符。但如果查询涉及到 5 个表乃至更多的列[字段]你就知道这个技巧多有用了。