每年需要更改数据库架构.应该使用哪种策略?

2 sql versioning schema obsolete

每年我们公司都会举办会议/展台,参加者可以在展会上展示他们的产品

我们有一个网络应用程序,让参与者报名参加会议.他们可以输入诸如公司名称,账单信息等信息.

似乎参与者需要输入的信息的要求每年都有所不同.

IE,一年参与者可能需要输入他们想要的展位大小,明年不再需要,等等.一年,您可能只需要输入所需的总数m ^ 2,而在第二年,您可能需要添加所需的长度,高度和楼层数.

多年来,这已经导致数据库架构变得非常疯狂.我们现在在我们的数据库中有很多"过时的"字段和表格,它开始看起来很混乱.由于历史原因,我们不能只将模式重置为每年的基础知识.我们可能需要旧会议的一些数据.

所以:有没有人对我们如何处理这个问题有个好主意?我能想到的唯一解决方案是

  • 版本我们的每个会议的数据库即
  • 将所有"变化"信息存储为xml

如果有人对如何处理不断发展的数据库和处理过时的数据有一些好的文章,那就太好了!

HLG*_*GEM 5

就像我不想这样说,这可能是实体 - 属性 - 值结构最有效的情况.

http://en.wikipedia.org/wiki/Entity-Attribute-Value_model

请注意,这不是一个轻易使用的模型,它存在重大问题.但这恰好是它旨在解决的问题.