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

【问题标题】：Database schema changes needed yearly. Which Strategy should be used?每年需要更改数据库架构。应该使用哪种策略？
【发布时间】：2019-03-12 01:02:04
【问题描述】：

我们公司每年都会举办一次会议/展台，参与者可以在这里展示他们的产品。

我们有一个网络应用程序可以让参与者注册参加会议。他们可以输入公司名称、帐单信息等信息。

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

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

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

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

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

【问题讨论】：

【解决方案1】：

尽管我不想这么说，但这可能是实体-属性-值结构最有效的情况。

请注意，这不是一个可以随便使用的模型，它存在重大问题。但这正是它旨在解决的问题。

【讨论】：

【解决方案2】：

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

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

这是一种非常幼稚的方法，即使这样做也不会是我要建模的最终状态（我可能会有另一张表将一年与一个问题相关联，这也是我将公司联系起来的方法。这样我们就可以一遍又一遍地重复使用问题）。

【讨论】：

【解决方案3】：

“我们的数据库中现在有很多‘过时’的字段和表，而且开始看起来很混乱。由于历史原因，我们不能只是将架构重置为每年的基础。我们可能需要一些旧会议的数据。”

如果您可能需要它们，它们也不会过时。

不过，我一般都会对前端进行编码。这意味着拥有一个可以处理任何形式的展台区域配置的系统（在您提供的示例中），如果应该发生的话，将来可能会更多。

如果您有“standarea”（m^2 中的面积）、“standsize”（长度、宽度、高度等）之类的表格 - 那么您的模型中就会有对象来匹配这些（StandArea、StandSize） - 这些都可以扩展一个通用的基类 StandData。

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

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

【讨论】：