问题描述
是否将所有有关会员的字段都放在会员表?遇到临时添加会员字段怎么办？
解决方案
解决方案二：
可以关联别的表设一个或多个关联主键即可。比如你现在是会员表有三个字段idnamesex你现在加一个信息表有N多字段主键关联idname即可其他字段随便添加什么兴趣爱好之类的、查询的时候关联出来就可以了。
解决方案三：
在会员表里，预留一部分字段。做临时添加用。
解决方案四：
比如在会员表添加一个字段:IsTemp类型bit临时添加的IsTemp为Fasle不是临时添加的IsTemp为True
解决方案五：
呃,回帖完发现理解错了....1楼正解
解决方案六：
简单的就按照1楼的去做，复杂的，可以做成动态的。把字段名、字段类型插入到新建的一张表中，每次查询行列转换。
解决方案七：
一楼说得对啊··要加字段直接加个表然后关联起来不就成了··
解决方案八：
回复stubble：谢
解决方案九：
回复chz415767975：行转列的话，对于表查询是很大的考验。
解决方案十：
四个方法：（1）用一个字段存储多个字段，性能较低，编程简单（2）预留通用字段，程序定义它的类型，性能很好，编程简单，但是扩展有限（3）使用外键和动态生成的表，性能好，扩展性强，编程复杂。（4）使用ID-键-值的方式存储，这种方式性能最差，但是可以无限增加字段
解决方案十一：
ls答的太好了,我没什么多说了,再补充一个吧,用一个字段来存json,可以无限扩展,不过得记得维护好文档或注释,
解决方案十二：
引用9楼caozhy的回复:
四个方法：（1）用一个字段存储多个字段，性能较低，编程简单（2）预留通用字段，程序定义它的类型，性能很好，编程简单，但是扩展有限（3）使用外键和动态生成的表，性能好，扩展性强，编程复杂。（4）使用ID-键-值的方式存储，这种方式性能最差，但是可以无限增加字段
解决方案十三：
微软的crm,sp都是预留一大堆各种类型的字段。
解决方案十四：
引用12楼winner2050的回复:
微软的crm,sp都是预留一大堆各种类型的字段。
那会有很多冗余数据
解决方案十五：
引用1楼stubble的回复:
可以关联别的表设一个或多个关联主键即可。比如你现在是会员表有三个字段idnamesex你现在加一个信息表有N多字段主键关联idname即可其他字段随便添加什么兴趣爱好之类的、查询的时候关联出来就可以了。
如果“临时添加字段”不值得添加在会员表，那么添加在信息表能解决什么问题？为什么弄两个表？
解决方案：
引用13楼mingsmall的回复:
Quote: 引用12楼winner2050的回复:
微软的crm,sp都是预留一大堆各种类型的字段。那会有很多冗余数据
冗余null是吧？这是关系数据库的必然结果。你认为每行多出来十几个null值会占多大空间？
解决方案：
如果扩展的字段不参与查询，只做为显示的话，多加一个xml型字段就ok当然xml文本你可以任意构造，任意扩充，只要符合xml规定即可如果需要参与查询，那就一个扩展字段仓库表，一个多对多中间映射表
解决方案：
引用14楼sp1234的回复:
Quote: 引用1楼stubble的回复:
可以关联别的表设一个或多个关联主键即可。比如你现在是会员表有三个字段idnamesex你现在加一个信息表有N多字段主键关联idname即可其他字段随便添加什么兴趣爱好之类的、查询的时候关联出来就可以了。如果“临时添加字段”不值得添加在会员表，那么添加在信息表能解决什么问题？为什么弄两个表？
个人观点这个信息表可有可无即使日后删除也对系统不产生负面影响。
解决方案：
引用17楼stubble的回复:
Quote: 引用14楼sp1234的回复:
Quote: 引用1楼stubble的回复:
可以关联别的表设一个或多个关联主键即可。比如你现在是会员表有三个字段idnamesex你现在加一个信息表有N多字段主键关联idname即可其他字段随便添加什么兴趣爱好之类的、查询的时候关联出来就可以了。如果“临时添加字段”不值得添加在会员表，那么添加在信息表能解决什么问题？为什么弄两个表？
所谓临时添加字段,不是添加临时字段个人观点这个信息表可有可无即使日后删除也对系统不产生负面影响。
是动态添加一个字段,但是依然要永久保留,而不是可有可无
解决方案：
引用15楼sp1234的回复:
Quote: 引用13楼mingsmall的回复:
Quote: 引用12楼winner2050的回复:
微软的crm,sp都是预留一大堆各种类型的字段。那会有很多冗余数据
冗余null是吧？这是关系数据库的必然结果。你认为每行多出来十几个null值会占多大空间？
难不成预留的字段名字都是colunm1，colunm2，colunm3此类？