我们首先来通过一道题来探索数据库的设计，还是针对软件生命周期管理这个系统，我有这样一个需求，无论我系统怎么变化（增加减少模块），整体的表结构都不变，同时也不需要增加减少表，这里面我们还要考虑一点，就是在不同的公司，对字段的要求可能也不一样，再一些大公司针对缺陷管理可能需要50个字段甚至更多，不过对于小公司可能只需要20个字段就可以满足需求，综合上述的说明，表结构不能变，表不增也不减，所以难度之大可想而知，首先要应对增加和减少模块不会影响到表，我首先是这样设计的，把所有模块的名称放在一张表里，这样增加或减少模块只需要增加一条记录就可以了（这个之前讲过的和xml配置是一个道理的），然后把属性也单拿出来作为一张表，当我们需要添加属性的时候，只要在该属性表里面添加或减少字段就可以了，这也是我们通常所说的行列转置，然后通过中间表将属性表与模块表关联起来，另外还有一张就是存储数据的表了，这张表虽然不复杂，由于不同属性可能类型不太一样，所以要花费一些功夫把字段进行一定的转型操作，统一存储。
也有的人会这样想，我可以用一张很大字段的表，然后可以预留好多好多的字段，牺牲空间，来换取时间的方法，其实也是可行的，有的时候我们还得非这么做不可。
我下面举一个真实的例子，IBM的生命周期管理系统（具体叫什么名字我也没记住，大家有兴趣可以查一下），首先通过内部手段，把数据库结构弄到手，然后导入到EA中，映射出类图，以及之间的关系结构，首先映入我们眼帘的就是三张字段特别多的表，一个叫Are表，一个叫Were表，还有一个叫Latest表，那么这三张表都是分别用来做什么的呢，这个系统据说已经运行了十年之久，数据库从来都没有出现过问题，这是为什么呢，下面我们就依赖一起探索着几张大表的奥秘。首先Latest表是用来存放最新任务的，Are表是指今天未完成的任务表，而Were表指的是已经完成的任务。为什么要这样设计呢，设计人员发现一个规律两万名员工平均每人每天分得五个新任务，而每天未完成的任务数也是每人5个左右，所以这样设计有一个好处，就是保证了最新任务表与未完成记录表的记录数量维持在一定的水平不变，这也是其中的奥秘所在，但是有人会说了，已经完成的任务表岂不是越来越多，越来越大，确实是这样，不过我们有没有发现，已经完成的任务可能都是一些不变的数据，其用途主要是领导用来做分析报表使用的，首先我们可以这样做，把一些用于分析报表使用到的数据提取出来，也可以将这些不变的数据通过hadoop云技术进行分布式云存储。
下面再给大家介绍一种比较巧妙的方法，就是大字段法，首先我们要把一个对象变成一种可以被数据库存储的大字段的形式（把对象序列化成2进制，16进制，或者是json格式，也可以是自定义格式）来进行存储，不过这样存储有一个弊端，就是我在进行数据分析的时候，由于不需要吧所有字段信息都要了解，所以不是特别好解析，还有就是编程的一些困难，这时有的同学又给出了解决方案——可以把这些用到的字段单列出来，的确这也是一种很好的解决方案。
还有一款软件就是IBM的CQ，这里面用到了一个数据字典的概念，首先创建一张主表，然后系统会根据数据字典来动态生成字表。原理是这样的，不过具体是怎么操作还得等以后细细研究
最近有一种数据库挺流行的，文档型数据库，也同时产生了一种概念叫NOSQL，例如Mongodb，是以一种OO的思想来存储数据，还有云技术存储DFS（Distributed file system），这种存储有一个弊端就是不能够频繁的修改，这样会造成数据的冗余。
其实数据库的设计还有好多方法，比如外置小文件的方法，通过数据库中的URL来指向文件路径，听说我国的民航系统就是这种形式，有上千万个这样的小文件；还有多表型，就是将不同类型的数据放在不同的表中，这种方式也解决了我前边所说的类型转换的问题。总之这些只是一些理论方面的东西，还是要在实践中去鉴定方案的可行性。