通常情况下，可以从两个方面来判断数据库是否设计的比较规范。一是看看是否拥有大量的窄表，二是宽表的数量是否足够的少。若符合这两个条件，则可以说明这个数据库的规范化水平还是比较高的。当然这是两个泛泛而谈的指标。为了达到数据库设计规范化的要求，一般来说，需要符合以下五个要求。

　　要求一：表中应该避免可为空的列。

　　虽然表中允许空列，但是，空字段是一种比较特殊的数据类型。数据库在处理的时候，需要进行特殊的处理。如此的话，就会增加数据库处理记录的复杂性。当表中有比较多的空字段时，在同等条件下，数据库处理的性能会降低许多。

　　所以，虽然在数据库表设计的时候，允许表中具有空字段，但是，我们应该尽量避免。若确实需要的话，我们可以通过一些折中的方式，来处理这些空字段，让其对数据库性能的影响降低到最少。

　　一是通过设置默认值的形式，来避免空字段的产生。如在一个人事管理系统中，有时候身份证号码字段可能允许为空。因为不是每个人都可以记住自己的身份证号码。而在员工报到的时候，可能身份证没有带在身边。所以，身份证号码字段往往不能及时提供。为此，身份证号码字段可以允许为空，以满足这些特殊情况的需要。但是，在数据库设计的时候，则可以做一些处理。如当用户没有输入内容的时候，则把这个字段的默认值设置为0或者为N/A。以避免空字段的产生。

　　二是若一张表中，允许为空的列比较多，接近表全部列数的三分之一。而且，这些列在大部分情况下，都是可有可无的。若数据库管理员遇到这种情况，笔者建议另外建立一张副表，以保存这些列。然后通过关键字把主表跟这张副表关联起来。将数据存储在两个独立的表中使得主表的设计更为简单，同时也能够满足存储空值信息的需要。

　　要求二：表不应该有重复的值或者列。

　　如现在有一个进销存管理系统，这个系统中有一张产品基本信息表中。这个产品开发有时候可以是一个人完成，而有时候又需要多个人合作才能够完成。所以，在产品基本信息表产品开发者这个字段中，有时候可能需要填入多个开发者的名字。

　　如进销存管理中，还需要对客户的联系人进行管理。有时候，企业可能只知道客户一个采购员的姓名。但是在必要的情况下，企业需要对客户的采购代表、仓库人员、财务人员共同进行管理。因为在订单上，可能需要填入采购代表的名字;可是在出货单上，则需要填入仓库管理人员的名字等等。

　　为了解决这个问题，有多种实现方式。但是，若设计不合理的话在，则会导致重复的值或者列。如我们也可以这么设计，把客户信息、联系人都放入同一张表中。为了解决多个联系人的问题，可以设置第一联系人、第一联系人电话、第二联系人、第二联系人电话等等。若还有第三联系人、第四联系人等等，则往往还需要加入更多的字段。

　　可是这么设计的话，会产生一系列的问题。如客户的采购员流动性比较大，在一年内换了六个采购员。此时，在系统中该如何管理呢?难道就建立六个联系人字段?这不但会导致空字段的增加，还需要频繁的更改数据库表结构。明显，这么做是不合理的。也有人说，可以直接修改采购员的名字呀。可是这么处理的话，会把原先采购订单上采购员的名字也改变了。因为采购单上客户采购员信息在数据库中存储的不是采购员的名字，而只是采购员对应的一个编号。在编号不改而名字改变了的情况下，采购订单上显示的就是更改后的名字。这不利于时候的追踪。

　　所以，在数据库设计的时候要尽量避免这种重复的值或者列的产生。笔者建议，若数据库管理员遇到这种情况，可以改变一下策略。如把客户联系人另外设置一张表。然后通过客户ID把供应商信息表跟客户联系人信息表连接起来。也就是说，尽量将重复的值放置到一张独立的表中进行管理。然后通过视图或者其他手段把这些独立的表联系起来。

　　要求三：表中记录应该有一个唯一的标识符。

　　在数据库表设计的时候，数据库管理员应该养成一个好习惯，用一个ID号来唯一的标识行记录，而不要通过名字、编号等字段来对纪录进行区分。每个表都应该有一个ID列，任何两个记录都不可以共享同一个ID值。另外，这个ID值最好有数据库来进行自动管理，而不要把这个任务给前台应用程序。否则的话，很容易产生ID值不统一的情况。

另外，在数据库设计的时候，最好还能够加入行号。如在销售订单管理中，ID号是用户不能够维护的。但是，行号用户就可以维护。如在销售订单的行中，用户可以通过调整行号的大小来对订单行进行排序。通常情况下，ID列是以1为单位递进的。但是，行号就要以10为单位累进。如此，正常情况下，行号就以10、20、30依次扩展下去。若此时用户需要把行号为30的纪录调到第一行显示。此时，用户在不能够更改ID列的情况下，可以更改行号来实现。如可以把行号改为1，在排序时就可以按行号来进行排序。如此的话，原来行号为30的纪录现在行号变为了1，就可以在第一行中显示。这是在实际应用程序设计中对 ID列的一个有效补充。这个内容在教科书上是没有的。需要在实际应用程序设计中，才会掌握到这个技巧。

　　要求四：数据库对象要有统一的前缀名。

　　一个比较复杂的应用系统，其对应的数据库表往往以千计。若让数据库管理员看到对象名就了解这个数据库对象所起的作用，恐怕会比较困难。而且在数据库对象引用的时候，数据库管理员也会为不能迅速找到所需要的数据库对象而头疼。

　　为此，笔者建立，在开发数据库之前，最好能够花一定的时间，去制定一个数据库对象的前缀命名规范。如笔者在数据库设计时，喜欢跟前台应用程序协商，确定合理的命名规范。笔者最常用的是根据前台应用程序的模块来定义后台数据库对象前缀名。如跟物料管理模块相关的表可以用M为前缀;而以订单管理相关的，则可以利用C作为前缀。具体采用什么前缀可以以用户的爱好而定义。但是，需要注意的是，这个命名规范应该在数据库管理员与前台应用程序开发者之间达成共识，并且严格按照这个命名规范来定义对象名。

　　其次，表、视图、函数等最好也有统一的前缀。如视图可以用V为前缀，而函数则可以利用F为前缀。如此数据库管理员无论是在日常管理还是对象引用的时候，都能够在最短的时间内找到自己所需要的对象。

　　要求五：尽量只存储单一实体类型的数据。

　　这里将的实体类型跟数据类型不是一回事，要注意区分。这里讲的实体类型是指所需要描述对象的本身。笔者举一个例子，估计大家就可以明白其中的内容了。如现在有一个图书馆里系统，有图书基本信息、作者信息两个实体对象。若用户要把这两个实体对象信息放在同一张表中也是可以的。如可以把表设计成图书名字、图书作者等等。可是如此设计的话，会给后续的维护带来不少的麻烦。

　　如当后续有图书出版时，则需要为每次出版的图书增加作者信息，这无疑会增加额外的存储空间，也会增加记录的长度。而且若作者的情况有所改变，如住址改变了以后，则还需要去更改每本书的记录。同时，若这个作者的图书从数据库中全部删除之后，这个作者的信息也就荡然无存了。很明显，这不符合数据库设计规范化的需求。

　　遇到这种情况时，笔者建议可以把上面这张表分解成三种独立的表，分别为图书基本信息表、作者基本信息表、图书与作者对应表等等。如此设计以后，以上遇到的所有问题就都引刃而解了。

　　以上五条是在数据库设计时达到规范化水平的基本要求。除了这些另外还有很多细节方面的要求，如数据类型、存储过程等等。而且，数据库规范往往没有技术方面的严格限制，主要依靠数据库管理员日常工作经验的累积。

1. CVS基本概念

　　CVS是很早的时候在Unix下发展起来的，它使用的术语比较特殊，需要先熟悉和理解，这是使用CVS的第一步。

　　Repository: 中文名称：仓库。它是 CVS服务器（可能在远程，也可能在本地）的根目录，我们所有的工作都保存在这个仓库中，包括源代码和这些代码的全部历史。你可以把Repository想像成一个仓库，仓库中有许多“木桶”，每个“木桶”就是我们的一个让 CVS管理起来的工程。对于CVS来说，这些“木桶”之间是没有什么关联的，删除一个“木桶”不会影响别的“木桶”。我们所想像的木桶，在CVS术语中，又叫模块（Module）。

　　Module：中文名称：模块。就是上面我们所想像的仓库中的“木桶”，里面放的是一个项目的所有文件（包括源代码，文档文件，资源文件等等）。在物理上，Module是CVS服务器根目录下的第一级子目录。

　　Import：中文名称：导入。我们本地有一个软件项目，里面有许多各种类型的文件，都需要用CVS进行版本管理，那么第一步就是把这个软件项目的整个目录结构都Import到CVS的仓库中去。经过这种导入，CVS将为你的项目创建一个新的“木桶”----Module，即模块。

　　Checkout：中文名称：导出。指将仓库中的一个“木桶”(Module, 模块)中的东西导出到本地的工作目录下，然后我们可以在WinCvs的管理下，进行工作，修改其中的内容。

　　Commit:中文名称：提交修改。我们在本地的工作目录下，对工程中的文件进行修改，这些修改，需要提交给CVS的仓库，这个过程，就叫Commit。你可以Commit一个文件，也可以Commit整个目录。

　　Update：中文名称：同步。它与Commit相对应，是从仓库中的“木桶”（模块）中下载你同事修改过的文件（别忘记你的项目有许多人共同参与），如果这个文件在你本地也有，就会更新本地的拷贝，如果你本地没有，就会把新文件下载到你的本地。

　　Revision：中文名称：文件版本。这是CVS中一个需要特别注意的概念，它指的是单个文件的版本，而不是整个项目的版本。基本上，单个文件每次的修改，经过Commit 之后，它的Revision都要改变一次，比如从1.1到1.2到1.3等等。特别要注意，单个文件的版本(Revision)与整个工程产品的版本（Version,或者Release）可以没有任何关系。例如，整个产品现在发行1.0版本(Version 1.0)了，但是产品的源代码文件中，有的文件版本(Revision)可能是1.9, 有的是2.1，等等。这很容易理解，因为为了发行产品V1.0，我们需要对源代码进行多次修改编译。

　　Release：中文名称：发行版本。整个产品的版本，例如VC5.0, VC6.0等。

　　Tag：中文名称：标签。在一个开发的特定期，对一个文件或者多个文件给的符号名，一般是有意义的字符串，如“stable”,“release_1_0”等。比如，我们对某个文件的1.5版本加上标签：“memory_bug_fixed”，借助这个有意义的标签，我们可以理解1.5版本解决了内存Bug，所以说Tag赋予了版本一些文字含义。

　　2. WinCvs的两种工作模式、工作流程与目录

　　理解上述基本概念之后，我们需要对WinCvs的工作方式有一个基本了解。

　　CVS工作于服务器/客户端模式（Client/Server模式）。WinCvs是CVS在Windows下的图形客户端。它有两个基本工作模式：

2.1 WinCvs作为远程CVS的客户端

　　WinCvs 的第一种工作模式是作为远程CVS服务器在本地的客户端使用。CVS由于是在Unix下发展起来的，在使用的时候，有很多命令行，命令行中又带很多参数，习惯于Windows的读者很难记忆这些命令行和参数。WinCvs提供了用图形界面使用远程CVS服务的直观方法。

　　在这种工作模式下，第一次使用WinCvs的基本流程如下：

　　1) 您首先要让CVS管理员给您分配一个用户名和密码，先使用WinCvs登录(Login)到CVS服务器。

　　2) 把本地需要CVS管理的原始目录导入（Import）到CVS服务器上去，使之成为CVS服务器上仓库(Repository)的一个Module。

　　3) 在本地硬盘上创建一个工作目录。

　　4) 从CVS服务器的仓库（Repository）导出(Checkout)一个Module到本地硬盘的工作目录

　　5) 从CVS服务器同步(Update)你同事的修改到你本地工作目录。在工作目录上进行工作，在这个过程中，把文件的中间版本(Revision)提交(Commit)给CVS服务器。

　　当您已经进行过上述流程，以后再使用时，就简化成只需要步骤1)和步骤5)就可以了。

　　2.2 WinCvs作为本地的服务器和客户端

　　如果没有远程CVS服务器，WinCvs 1.3版本能够在本地同时作为Server和Client来工作。其中，服务器端的功能是WinCvs启动CVSNT在后台实现的，CVSNT(www.cvsnt.org)也是一个开源项目，WinCvs1.3版本自带CVSNT，您不用单独安装。在这种工作模式下，你需要在本地硬盘上开设一个CVS仓库目录，它的作用和地位其实就和远程CVS仓库目录一样。

　　WinCvs工作在这个模式时，当您开始从头工作时，需要下面的工作流程：

　　1) 首先在本地硬盘上，创建CVS的仓库(Repository)目录。目录名可任意，一般是CVSRoot

　　2) 把本地需要CVS管理的原始目录导入（Import）到CVS服务器上去，使之成为CVS服务器上仓库(Repository)的一个Module。

　　3) 在本地硬盘上创建一个工作目录。

　　4) 从CVS服务器的仓库（Repository）导出(Checkout)一个Module到本地硬盘的工作目录

　　5) 从CVS服务器同步(Update)你自己从前的修改到你本地工作目录。在工作目录上进行工作，在这个过程中，把文件的中间版本(Revision)提交(Commit)给CVS服务器。

　　当您已经进行过上述流程，以后再使用时，就简化成只需要步骤5)就可以了。

　　无论WinCvs工作在上述哪种模式下，下面是它的工作流程图：

　　

　　从WinCvs的工作流程图中可以知道，WinCvs的工作涉及三个目录：一是原始目录，我们从这里把文件导入到CVS进行管理，从此以后这个目录下的文件就不再参与WinCvs活动了；二是CVS仓库目录，所有的Module都存放在这里，它可能是远程Linux下由CVS服务器管理员创建的，也可能是你自己在本地硬盘创建的，这决定于你工作在哪种模式下；三是您本地硬盘的工作目录，您在这里对文件进行多次修改和提交。

现在很多网站都用到Cookies，特别是用户的登陆以及购物网站的购物车。 Cookies 通常用来存储用户信息和用户在某应用系统的操作，当一个用户使用Cookies 访问了某一个应用系统时，Web 服务器将发送关于用户的信息，把该信息以Cookies 的形式存储在客户端计算机上，这可用来创建动态和自定义页面或者存储登陆等信息。
如果Web 应用系统使用了Cookies ，就必须检查Cookies 是否能正常工作。测试的内容包括Cookies是否起作用，存储的内容是否正确，是否按预定的时间进行保存，刷新对Cookies 有什么影响等。

　　如果到\Local Settings\Temporary Internet Files文件夹下查看每个Cookies文件是一件很麻烦的事情，这个时候就需要有工具来帮助我们。

　　1、Cookie Editor

　　http://www.proxoft.com/CookieEditor.asp

　　下载工具试用>>

　　Cookie Editor is an application that helps you manage cookies set by Internet Explorer, Netscape or Mozilla Browsers.

　　Cookie Editor allows you to maintain the level of your privacy by allowing you to see, edit or delete any unwanted cookies. It searches your drives for all IE cookies then displays them is easy grid-like format. You can examine content of any cookie or delete it.

　　For advanced users, you can also edit the contents of cookies. So, for example, if you want to change your zip code for 'movies.yahoo.com', or move up the expiration date of a given cookie, you could do so without even opening your browser!

　　比较大的特点是可以显示出IE，Netscape和Firefox的Cookie；因为Netscape和Firefox的Cookie不是存储在Temporary Internet Files文件夹下的，而是在Application Data文件夹下的对应文件夹里。

　　2、IECookiesView

　　http://www.nirsoft.net/utils/iecookies.html

　　下载工具试用>>

　　一个可以帮你搜寻并显示出你计算机中所有的Cookies档案的数据，包括是哪一个网站写入Cookies的，内容有什么，写入的时间日期及此Cookies的有效期限..等等资料。你是否常常怀疑一些网站写入Cookies内容到你的计算机中是否会对你造成隐私的侵犯！使用软件来看看这些Cookies的内容都是些什么呢！如此你就不会再担心怀疑了。此软件只对IE浏览器的Cookies有效。

 

　　3、Cookies Manager

　　下载工具试用>>

　　Cookies Manager helps you to select which cookies you want to keep and which cookies you want to delete. 

　　4、My Cookie

　　My Cookie是一款可以实时查看、修改IE内 Cookied的软件。并且可以设置 Cookie值的生命周期。