数据库动态扩展字段

Posted 2020-10-20 山的那边是什么

     最近在负责一个平台，需要和不同系统进行对接，需要用到数据库的动态扩展字段。

     现在比较流行的扩展字段方法，有大概如下把，①预留很多列进行扩展，②使用版本号的方式来进行扩展，③使用Key+Value的形式进行扩展。下面我讲讲我对这几种方法的看法。

     可能很多人会问，你要增加一个字段，那不就直接在数据库里的对应表加就结了，哪有什么扩展的设计呀，哪天要加字段了就加呗，可以为空就为空，不可以给个默认值完事。确实是这么简单，添加一个字段如果是允许为可空类型确实是一点问题都没有。如果你添加一个字段需要不允许为空，然后又在1KW左右的数据量表里面添加的时候，就可能需要花费很长时间，当然这些操作都可以在夜深人静的时候加（加完之后，改一下代码这个也能做好）

     （一）为可能需要扩展的表，预留一些字段

          数据库预留一些字段，就是以防万一，防患于未然，等到需要的时候，就不需要在表中增加新的字段了，而且这么做的话，一个表里面的数据应该是存储在相邻的物理空间。其实这个问题是不是真的解决我们的需要呢，因为预留字段的特点是col1,col2这种命名，是不是很好维护了，等过了几年再来看这个是否合理呢。

           上面这种就是属于“过度设计”，我们应该做的就是按需设计。

     （二）使用版本号+通用列的方式来进行扩展

        

 

         类似于这种0，如果有字段变更的话，用一个通用列来进行存储，但是用这种结构特别不好，不过SQL Server2016已经支持Json格式了，所以也慢慢得变得可行了。

     （三） 使用Key+Value的方式进行扩展

         下面说说，我最常用的Key+Value方式来进行动态扩展。

         拿最近涉及到的业务系统来举例子，对于不同用户

         

       下面重点讲讲我们这个的做法把，最初的做法是一个用户基础表（UserBase)，然后分别为每个系统设计对应的表。比如对应业务系统A（AEX(扩展表），BEX类似于这样。因为对我们整个平台来说，每个业务系统，关注的属性都是不一样，并且都是不确定的，每个业务系统都有自己的业务属性。根据这些情况，我们就把AEX设计成了可扩展的表形式（AEX（主键Id,UserId,Key,Value))。一开始我们是这样设计的，写代码的时候，你会发现我们太依赖这个KEY值了，需要用到KEY值对应的Value的时候，都是拿KEY值对应的内容来进行比较，并且KEY值也不能太长，太长会给我们造成负担。所以我们有了改进的版本，就是要摆脱这种依赖关系。

      摆脱依赖的方法，在面向对象设计，最普通的就是引入第三者，没错，我们需要引入一个专门的配置表来管理这些KEY值，暂且就叫KeyConfig表(Id ,KeyName)  AEX(主键Id,UserId,KeyId,Value)。那么相对应的Value如果有多个值，也可以设置一个ValueConfig表来存储。这些变化都需要根据业务来进行取舍。