问题描述
比如有个Book表，有id, name, isbn等列表示基本信息，但是不同的商家对Book表有不同的其他需求，有的还需要A属性，有的则还需要B属性，或者说某一天随着需求变化，我们要扩展Book的信息，但又不希望以加列的方式更改Book表，应如何设计呢？考虑了一下，可以另外创建两个表，一个叫做ColumnExtend, 一个叫做BookDetail表，ColumnExtend里面列有id, columnName，datatype列，BookDetail则有id, columnExtendId, BookId，varcharValue, numberValue, .....等列ColumnExtend只是被扩展的一个属性的描述，说明Book表扩展的属性的名称，类型，而BookDetail表里则含有id(主键), columnExtend的id(说明是哪一个扩展属性)，BookId（哪本书），value（值是什么）由于事先不知道被扩展的属性的类型，所以值的列就很多了，有varcharValue, numberValue.....一大堆。这样当新扩展一个属性的时候，往ColumnExtend表里加一条记录，同时对于每一本书来说还需要在BookDetail里面要插入一条数据（默认值）。这样数据多了的时候，会很麻烦，效率极其低下。而且觉得维护BookDetail中的vacharValue, numberValue, clob, blob,等等一大堆列也是个问题。。。希望各位指点迷津，有更好的解决方法不吝赐教
解决方案
其实如果想把业务系统产品化就需要对业务高度抽象化 你不应该去适应个别业务 应该让业务适应你或者你就不要做业务系统 做业务框架引擎 所有的表单和数据库都动态生成 然后进行2次开发 类似于freemarker 呵呵
解决方案二：
你的方案是，为了避免对横表形式的主表增加过多的字段（而有些字段不是所有的记录都需要的，有可能一半以上的记录该字段是空的，这个是我的一点经验），增加了纵表形式的扩展表，这样做事无可厚非的，记得看JBPM3源码的时候，那里也有类似的东西。另外，以前做过的一个项目，主表记录4KW+，扩展表就有几个亿的记录了，另外杂七杂八的相关表有6、7张。至于性能问题，是可以做优化的，索引，符合索引，分区，分表，分库，sql优化，等等。和横表维护相比，纵表的维护是麻烦点，但是，做好了也是比较有成就感的。见的多了，就不怕麻烦了。