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

Question

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

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

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

I.E，参与者可能需要一年输入他们想要的展台尺寸，第二年不再需要展台，依此类推。 一年，你可能只需要输入你想要的总数m ^ 2，而在第二年，你可能需要添加你想要的长度，高度和楼层数。

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

那么：有没有人对我们如何处理这个问题有个好主意？ 我能想到的唯一解决方案是

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

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

Answer 1

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

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

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

Answer 2

我会考虑对所有扩展数据使用名称 - 值方法。基本上，您可以逐年定义静态数据。这将是公司信息，例如地址的定义不会年复一年地变化。这些将正常建模。

然后，您将定义一个表格，其中包含您所有问题的主人，并将以某种方式链接以告诉您这些问题对哪些年有效。此表还可能指示有关该问题的其他属性，可以让您在其上动态创建GUI。诸如正则表达式之类的东西，用于验证数据类型等。

这是一种非常天真的方法，即使在这样做之后也不会是我想要模仿的最终状态（我会在另一个表格中将一年与问题相关联，这也是我将公司联系起来的内容。通过这种方式，我们可以反复重复使用问题。

Answer 3

“我们现在在我们的数据库中有很多'过时的'字段和表格，而且它开始变得非常混乱。由于历史原因，我们不能仅仅将模式重置为每年的基础知识。我们可能需要来自旧会议的一些数据。“

如果你可能需要它们，它们就不会过时。

然而，我会对前端进行一般编码。这意味着拥有一个可以处理任何形式的展台区域配置的系统（在您给出的示例中），如果发生这种情况，将来可能会更多。

如果你有像“standarea”这样的表格（m ^ 2区域），“standize”（长度，宽度，高度等） - 那么你的模型中的对象就可以匹配这些（StandArea，StandSize） - 这些可以扩展一个公共基类StandData。

一年一个表获取数据集，第二年另一个表获取数据。您的DAO将尝试从每个表中加载每个对象（通过父，err，stand_uid字段），然后将“ConferenceApplication”对象中的StandData字段设置为它发现的任何内容。

另一种选择是在一个表中包含所有可能的字段，并允许它们为空。