我觉得创建一个应用系统的数据库很不容易，尤其是需求还一直变化的系统。
虽然范式很重要，但是如果只是根据需求文档来创建数据库，会出现一个很不好的现象。比如现在知道了一个对象有多少属性，然后确定主键生成规则，最多添加外键约束，至于长度，类型都是必须的，然后一张表就出来了。这样的做法隐含了一个问题，这个对象的属性之间是不是没有任何关系了，比如姓名和年龄和性别这些当然是没有关系了。但是如果属性之间还是有关系的，数据库中的表就无法表达出来了。我现在参与的一个项目（一个老项目），它的数据库中的表就有这个问题，其中有这些字段，责任人，承办人，接谈人，法官。他们大多数时候是一个人，由于文档的缺失，我只能从字面上去理解这些字段，这些字段内在的一些联系我就无法弄清楚了，到底什么时候他们是一样的，什么时候不一样呢？
也许可以用文档缺失来解释这个问题，数据库本身设计不存在问题？但是后来在使用这张表的时候又发生了一件令人无法原谅的事情。由于是老项目，已经不知道经过了第几个开发团队了，再加上我现在的项目是中途从另一个团队转过来的，为什么这么说呢？因为他们已经完成了部分需求，我们是紧接着完成剩下的需求，这导致他们完成的代码是没有经过测试的。不能保证是正确的。我发现的问题是某个页面一直不显示数据，跟踪代码到DAO层，一直分析它的SQL语句，在排除掉几个查询条件之后，我把问题锁定在其中一个判断条件，他用的是责任人这个字段去比较某个条件。我再去数据库中查询出我做的那条记录，发现责任人字段是一个大大的NULL，我接着查询出所有的记录，惊讶的发现所有记录的责任人字段都是NULL，这就是查不出数据的原因了。我都怀疑责任人字段是不是已经被抛弃了，最后使用接谈人代替了。
虽然不明白当初那个开发人员为什么选择的是责任人来作为判断条件，我猜测是根据需求来做的，而需求又是根据语义来写的，他觉得这里使用责任人才是符合现实需求的。很显然数据库中的字段已经不能完全符合对象的属性，或者说符合最初需求的意义了。责任人字段已经不知道应该在什么时候去插入到数据库中去了，但是当前的需求人员还不知道，还在使用责任人这个概念。这种现象显示了维护一张具有相关性属性的表是困难的。
数据库中表的字段是没有详细解释的，更不会去揭示和其他字段之间的联系了，比如说时间先后关系，包含关系，运算关系等。所以请留下详细的说明文档，如果只是简单的把zrr翻译成责任人，其作用基本为零。
本来想这些“重复”的字段，可不可以只要一个呢，仔细一想就会发现，这些字段之间虽然有关系，但是又不是很密切，代表不同的现实意义。所以是不能去掉的，解决问题的办法还是需要详细的文档，详细的说明什么时候初始化，什么时候可以使用，什么时候他们之间是相关的，只有这样才能避免开发人员混用来这些字段。
如果说有一张表中有两个字段物品价格，物品数量，这时候要是还有一个总价字段，那就是没有必要的，这个例子举的差强人意，不太符合这里的情境。
上面说的情况属于一张表的字段之间具有关系，导致维护困难。今天又发现两张表之间也有类似的情况：A表中的a字段，在B表中做了冗余字段，叫做b。可惜的是a字段不是主键，b字段也不是外键。无法从数据库中直接看出来两者之间的关系，我也是无意间在页面上发现都是用同一个代码值取数据，才理解这两个字段是同一个意思。冗余字段就是为了减少关联表查询的，如果不知道那个字段就是个冗余字段，那不是白费劲吗，还得做关联表。