修改其底层数据库模式的应用程序答案

【问题标题】：Application that modifies its underlying db schema修改其底层数据库模式的应用程序
【发布时间】：2010-03-27 02:45:23
【问题描述】：

在什么情况下（如果有）您会允许应用程序更改其底层数据库架构？ IE。添加新列。

编辑：稍微详细说明是什么促使我提出这个问题。我的系统从其他系统接收报告文件，并将获取的数据保存在“报告”表中。报告包括几个现在硬编码的“参数”：日期、金额、单位价格。此参数保存在“报告”表中的适当列中。我们需要介绍动态（通过 Web 界面）添加新参数的可能性，这些新参数可以从报告文件中读取并插入到数据库中。

一种选择是以某种序列化形式保存报告，但存在性能问题。每天会有上千个报表，需要通过参数值查询“报表”表。

【问题讨论】：

标签： schema database

【解决方案1】：

首次加载新版本时。这与将数据库分配给每个唯一实例的系统尤其相关。数据写入应使用系统变量进行标记，并在更新之前使用类似的东西进行测试

show columns from test like 'new_column';
if ( ! new_column )
  alter table add column new_column after some_column

关于其他帖子，如果您在相同的数据库架构（但这些架构的不同实例）上运行具有增量版本控制的系统，则管理该更改的唯一方法是以编程方式更新数据库 - 否则您将应用程序版本（即 1.0 和 1.1）与架构之间存在不一致 - 在这种情况下，不可能同时在所有数据库中应用数据库更改。

【讨论】：

+1 好点（尽管我会尝试将任何更新步骤与应用程序代码本身隔离开来，我知道这可能会让人毛骨悚然！）

【解决方案2】：

简单地说，从来没有。更改数据库结构应该是受控的更改 - 允许应用程序（例如，旨在将数据库从一个版本升级到另一个版本的应用程序除外）破坏了这种控制。

也许您可以详细说明为什么您认为这是一个好主意，或者是什么促使您提出这个问题。

【讨论】：

【解决方案3】：

我不会——永远不会。我知道可以对 POJO 进行更改并允许 Hibernate，例如，传播数据库所需的任何更改，但恕我直言，这是一个坏主意，因为它消除了对架构进行适当配置管理的能力。

编辑：可能的例外：请参阅 Andy 的回答（尽管我仍会尝试将更新步骤与应用程序本身分开）。

【讨论】：