数据库设计之---预留通用扩展设计

  在软件工程上，软件过程中的软件维护期总是在软件的生命周期中占用了绝大的时间。软件开发完成后，软件的需求在不断的改变和修正。而由此带来的在软件架构上的缺点和不足就会凸显，怎么能让软件的信息在这万变的环境下，能顺应不同的需求的改变而做出最小的变动了？

这就要求数据库设计人员，不仅要在软件的开发初期就要对软件的定位、作用等与之相关联的各种信息吃透，而且要考虑软件在未来的发展中

有可能的新的需求。

 

  诚然，我们无从得知未来会是怎么发展。但是我们可以预测他，并且把这种可能的变化的代价降到最低。所以在软件架构中的数据的架构在软件开发初期显得尤为中要。这里结合最近的一个项目中的数据库设计中一些关于某些扩展的实践与大家分享。

 

  数据库设计中，想到扩展，第一的想法是，预留字段，这是最原始的方法。也是常用的一种方法。但是，如果之后的需求变动的很多，那么就会带来很多的麻烦，预留多少是多，曾经有幸在国内ERP软件龙头老大的企业用友从事开发工作，亲历大数据量数据库的设计和架构。甚至有些表的预留字段有几十个。当然，这和业务系统有很大的关系。

 

 本文主要分享的是数据表的预留，数据表的预留不是要预留N个表，而是根据业务系统的发展考虑，预留几个表。那么怎么能让这几个表能为之后的扩展通用了？分享一下我的实例：

 

Table

-------------------------

a  | b | c  |  d      

 

比如Table表中，现在业务系统只需要a,b,c,d四个字段，而未来的也许需求的扩展不知道要加多少，数据库应该如何设计？如果采取预留字段的方法，预留多少？类型如何？都是问题。我们的扩展表的功能的好处是不管你的也许需求如何的变更，我们都可以适应他，做到一劳永逸。

 

..................................................................................................................................................................................

一.设计主表（N个表中的其中）

 

Table1

--------------------------------

a  | b | c  |  d  | extendID     

 

 

Table2

--------------------------------

e  | f | h  |  i  | extendID     

 

 

 

说明:多添加一个扩展列:extendID 类型为 GUID Varchar(32) ,取值为32位GUID(我自己的做法,当然也可以设计为其他的类型)

 

.................................................................................................................................................................................

二.设计通用扩展表：

 

extendTable

---------------------------------------------------------------------------------------------------------------------------------------------

extendID（varchar）  | keyfield（varchar） |  type（int） | Value1（varchar）| Value2（double）

 

说明：extendID，和主表对应GUID

         keyfield，扩展的列名（在检索的时候很重要）

         type,数据类型,比如 int = 1,char = 2 ,text = 3

         Value1,记录值 字符串类型

         Value2,记录值  数字类型 (这里说明,想用字符串和数字类型,来表示所有的扩展值)

 

其中,extendID 和 KeyField 作为联合主键.  这样以来,就可以解决某条记录,某个表的N个字段的扩展.

................................................................................................................................................................................

三.表之间约束

 

主表和扩展表如果有如上的对应,那么必须建立相应的约束和触发器.

 

如Table1 和 extendTable 间有扩展关系,那么要设计如下的约束:

 

（注意，不需要主，外键约束关系，因为Table中的某些行是不需要扩展的）

 

触发器1：table—delete 触发器，当table表中的某条数据确定要删除事，extendTable表中想关联的数据也要删除

触发器2：extendTable--delete触发器：不能无条件下删除和table中相关联的数据

触发器3：extendTable--update触发器：不能更改无条件下和table表相关联的 extendID 和keyfield 的值

 

 

 

至此，一个万能的可扩展的数据库,设计完成,当然还有考虑不周的情况,请各方高人赐教.