如何应对表结构经常变化？

作为架构师或者开发人员，面对业务方提出的数据结构变化的需求总是很头痛的，今天让你加个描述字段，明天让你再加个什么标记，后天又需要增加一个时间戳，千奇百怪，层出不穷，实在头痛。但是，我们不能随意的指责什么，因为业务在发展，而且我们不能也不应该因为技术或者实现的原因去否决一些业务变化，毕竟技术是什么？真正产生价值的还是业务！

 

那，在实践中，我们如何面对这种无法避免而且往往很难预期的数据结构变化呢？

 

第一种方法，预留字段

既然很难加字段，就预先留好一些备用，比如加上10个Date,20个VARCHAR，10个Number之类的，虽然看起来猥琐了点，而且没那么灵活，其实还是很实用的，生产中也有不少人使用，不过因为预先留的字段一般是没什么含义的，需要有额外的信息来描述他，COL1是什么含义，COL2是什么含义，演变到后来有的就干脆更极端，所有字段都是无意义的名字，全靠外部的meta信息来描述，这种用法据我所知至少有三个地方在使用，两个是我亲自听到设计者描述的，另一个是别人告诉我的

 

不管怎样，预留字段的方式还是很解决很多问题的，而且基本不影响性能，除了额外的meta信息描述外，也没有其他的负担。

 

第二种方法，使用复杂字段

这个应用的场景不是很多，在某些特殊要求下还是很有用的，比如，某个业务实体（某张表），有一些标记位，都是true/false之类的标记，可以理解为这个实体的一些属性，经常需要添加，这种情况，在生产中我们使用过用一个数字，按位来表示这些标记的，比如第三位表示他是不是付费用户，第四位表示他是合作方来的用户还是自己注册的，等等。还有一种情况，需要更复杂的属性列表，属性个数经常变，可以考虑使用一个文本字段，保存结构化的数据，比如自己定义一个xml的格式

 

使用复杂字段的好处就在于比较灵活，同一类型的数据可以放在一起（实际上相当于把应该是一个关联表的数据放一个字段里了），操作的性能也不错，但是复杂字段里面的内容查询比较困难

 

还有一种方法，将数据的存储和索引（需要查询的内容）分开存放，相当于主表就一个key-value，value就是一个大的xml（或者其他的一坨），把需要查询的字段放到其他单独的表里去，可以参考friendfeed如何使用mysql，这是一个实际的例子。实际上在02－03年的时候，老是面对这样的问题，我就在考虑这样的方案，我当初的想法是，用bdb来存储数据（就是那个key-value）了，要检索的数据放到lucene里去，但是因为那个系统对实时性的要求而没法实施，但是并不是每个系统都要求这么实时的，在有些地方还是可以考虑使用的

 

另外，还有column based db，也可以很好的解决这个问题，实际上他就本本回避了加字段的问题，不过现在似乎没有性能很好的实现

 

上面这些方案的，都有局限性，选用的时候要看场景的，而且有可能今天作出的决定是对的，过了两年就变的不适合了，事情总是在变化的嘛...

评论

35 楼 zhi_nan_7 2014-10-08  

做一个软件，需求是这样的：银行软件，需要对（excel）表格定义的指标，产生报表（也就说这些报表是有哪些字段，字段与字段之间父子（如包含，其中）关系也还不知道），需要对产生的报表增删改查，表格定义了指标之间应校验关系，与指标字段值应符合的值的阀值，生成报表，打印报表，报表预览。请问这样的软件该怎么设计呀。
    要说能确定也大概是该excel表格定义的指标的结构是固定的。表格单元格之间父子包含关系，只能通过给过的模板来识别（报表的excel强调只能两级父子关系）.
    请问如何设计，是否这样：
    做一个表格元表：列ID，列名，属性，与其它字段校验关系，应在统计报表模板的第几行第列，父列
     这样动态生成表格。然后根据生成的表格，根据模板程序动态生成该表格的增删改查，打印程序（这也太难了吧，交互性也难保证（因为表格有的长的有200多列）也不知道怎么实现呀）。
    感觉这个需求一句话就是“一张excel表格得到一个软件”。
    有没有可简化的实现办法：它说可以他们用户提供模板，提供指标说明信息。
    这个软件怎么简化设计，交互怎么设计？
    9000元这个软件，真是要死人。

34 楼 argan 2010-01-14  

lingqi1818 写道

我想貌似这个没有绝对100%OK的方案，只能是在问题发生的时候对方案本身进行抉择和权衡了。。。

是的，从设计上，谁愿意搞这么“猥琐”的东西啊，现实是残酷的，活着的才是好的

另外，所谓的规范就是来践踏的，所谓的范式，只是用来权衡的，很多时候完全遵守这些东西，死的最快

所谓的架构，就是权衡各种因素得出的一个选择而已，在不同的场景面对类似的问题选择相差会很大，而且业务在发展，场景在变化，架构也不可避免的在退化，也许当初一个很好的选择，情况发生变化之后就变成垃圾了

所以啊，没法单纯的说一个东西的好坏的，呵呵

33 楼 lingqi1818 2010-01-14  

我想貌似这个没有绝对100%OK的方案，只能是在问题发生的时候对方案本身进行抉择和权衡了。。。

32 楼 lingqi1818 2010-01-14  

回复咋都那么偏激。。。

31 楼 huacnlee 2010-01-12  

zhanglian123 写道

预留字段最省事,改起来最快;
我们一般都是这样做;每种类型预留10个;
另外一种,我们也采用就是设计一张关联表,
假设有A,B;两张独立表;设计一张C将他们关联起来;
A,B存放各自信息;C表只存放关联关系.
不过个人意见,如果时间比较充足,还是重新设计表,可能这样改动量比较大

强烈反对预留字段的做法

• 预留字段会使得数据库里面出现一大堆模棱两可的字段名，项目时间久了容易忘记，而且其他人来接手的时候看不明白
• 你一开始预估的字段有可能永远都不会用到，或者不够用，到头还还是得增加字段

30 楼 huacnlee 2010-01-12  

使用 ORM，尽量将对数据库的操作进行抽象、封装

在 Rails 里面表结构变化其实没有那么可怕，我们敢一开始的时候只设计唯一需要的，等到后面再有需求的时候在加上去。
因为 Rails 的设计使得数据库结构变动更改简单安全

29 楼 LSQ6063 2010-01-11  

pf_miles 写道

agan??
我的看法是..数据库设计不为了“未来”而设计，所以我反对“预留字段”的方法；
依我个人的经验上讲，表结构做到3范式，并且任何字段都不带结构(只是一个意义单一的值而已)，总体来说这样的数据库设计是很好扩展的；
“很好扩展”基本上是指如果业务要新增概念，那么只需要通过添加字段或者添加新表完成扩展，而不是更改字段本身或者删除字段（有点“开闭原则”的意思，我觉得不管是对象设计还是数据库设计这点是部分共通的）
看得出来你已经对这些“很好扩展”的扩展进行抱怨了；
确实，如果业务变化很快，那么就算变化朝着正常方向发展（只增不删改），也不免会让人觉得烦；
我觉得这种烦恼很大部分是因为我们不仅在代码中维护了所有的业务概念，同时在关系型数据库表中也维护了一份业务概念——我们要具体到某个字段来存储，表结构实际上非常具体地展现了业务数据——这就导致业务一变，除了代码要变之外，数据库表结构也可能变；
这样我觉得有意思的事情就来了：你需要用数据库进行关系运算么？
数据库表非常具体地展现了所有的业务字段细节，为的是做关系运算，比如连接查询；
简单看了一下你提到的“复杂字段”和后面的“key-value”方案，如果这样的方案能满足你的业务需要，那么说明你的业务是不需要数据库做关系运算的，进而也不需要关系型数据库了...所以这里你不妨考虑一下对象数据库
就像bigTable一样，所有的东西都有一个identity取出来，以一个对象的形式，所有的业务逻辑就只存在于代码中

我也觉得不要为未来而设计预留字段！
我曾经在接收一个系统时，当时的同事预留了很多字段，真的没什么意义！计划永远赶不上变化！扩展并非能通过预留字段来解决问题。

28 楼 qingfengjushi1 2010-01-10  

感觉楼主的第二种方法查询性能会有问题, 难道检索时还要根据位数截串吗? 海量数据怎么办? 此字段索引如何建立?

27 楼 拥抱变化之美 2010-01-08  

表结构经常变化说明：
1 实体定义中有"易变的"attribute（比如age属性），你应该将其分解出来；
2 实体中杂合了太多的业务规则（比如顾客的消费总额与折扣率），你应该将其分离开来。

26 楼 argan 2010-01-08  

看来还是场景，或者说是行业的不一样，面临的情况差别很大

如果是银行、金融、电信之类的很成熟的核心业务，变化是不多的，但是，考虑一下像淘宝、腾讯这种很不成熟的业务，很多都是尝试性的东西，基本上一开始就想的很完善是很难的

还有，给客户做系统和做自己的系统，这个心态也完全不一样的

另外，对于互联网应用来说，因为要考虑7X24的问题，数据量很大要动态增加或者修改字段这个实在是很难的一件事情

25 楼 anky_end 2010-01-08  

ywlqi 写道

我比较不喜欢预留字段的方法，看到预留字段的字段名就感觉难受，也想不明白等到业务需要时才“临时”增加字段有什么不可以

效率和安全性？

比如已经有以亿计算的数据时候，改动结构会有什么问题么？

24 楼 vv_1024 2010-01-05  

业务一直要变化，是否可以考虑在业务层上再抽象出一层，就像 jbpm

23 楼 liu78778 2010-01-05  

拥抱变化吧, 顺便让客户填写需求变更单

22 楼 niwtsew 2010-01-04  

字段名动态化...

21 楼 dragonisflying 2010-01-04  

数据库设计需要用心去做

20 楼 ora92 2009-12-31  

改来改去确实很头疼，但没办法，为了生存

19 楼 dengmingfeng 2009-12-30  

如果使用hibernate，加几个字段还是很快的。查询不用*，基本上改动也很小。
如果使用的是jdbc查询，所以的sql语句最好放在一个文件中

18 楼 Ihavegotyou 2009-12-30  

binlaniua 写道

现在的数据库应该都支持正则表达式查询吧

正则的效率不高,有的数据库支持也不够好. 并且各自的正则写法可能不一样。

http://ihavegotyou.iteye.com/blog/560053

17 楼 berlou 2009-12-30  

预留字段太恶心了， 不推荐用预留字段。还需要整个文档描述一下哪个字段究竟是什么含义。
还是好好考虑设计吧， 既然不是做产品的， 应对敏捷变化是必然的。

16 楼 ywlqi 2009-12-30  

我比较不喜欢预留字段的方法，看到预留字段的字段名就感觉难受，也想不明白等到业务需要时才“临时”增加字段有什么不可以