Oracle 如何管理生产数据库的架构升级？

这似乎是一个被忽视的领域，需要一些真知灼见。您的最佳实践是什么：

• 制定升级程序
• 发生错误时退出
• 同步代码和数据库更改
• 部署前的测试
• 修改表格的机制

等等。

一般来说，我的规则是：“应用程序应该管理自己的模式。”

这意味着架构升级脚本是应用程序的任何升级包的一部分，并在应用程序启动时自动运行。出现错误时，应用程序无法启动，升级脚本事务未提交。这样做的缺点是，应用程序必须具有对模式的完全修改权限（这使DBA感到烦恼）

我使用Hibernates SchemaUpdate特性管理表结构取得了巨大成功。让升级脚本只处理实际的数据初始化和偶尔删除列（SchemaUpdate不这样做）

关于测试，因为升级是应用程序的一部分，所以测试它们成为应用程序测试周期的一部分

事后思考：考虑到其他帖子中的一些批评，请注意规则上写着“这是自己的”。它只适用于应用程序拥有模式的情况，通常情况下软件作为产品销售。如果您的软件与其他软件共享数据库，请使用其他方法。

我非常喜欢帮助创建SQL包以更新数据库架构的产品。数据库脚本可以添加到源代码管理中，以帮助进行版本控制和回滚。

这是一个很好的问题。（很有可能这将结束一场规范化与非规范化数据库的辩论……我不打算从这场辩论开始……好了，现在就开始一些输入。）

我做过的一些事情（当我有更多的时间或需要休息时，会增加更多）

客户机设计-这就是VB内联sql方法（即使是准备好的语句）让您陷入麻烦的地方。你可以花很长时间去寻找那些陈述。如果您使用Hibernate之类的工具，并将尽可能多的SQL放入命名查询中，那么大多数SQL都只有一个位置（没有什么比尝试测试某个If语句中的SQL更糟糕的了，只是在测试该If语句时没有达到“触发器”标准）。在使用hibernate（或其他ORM）之前，当我直接在JDBC或ODBC中执行SQL时，我会将所有SQL语句作为对象的公共字段（具有命名约定）或属性文件（也具有值的命名约定，如PREP_STMT_xxxx。并在a中启动时使用反射或迭代值）测试用例b）应用程序的启动（有些rdbms允许您在执行前使用准备好的语句进行预编译，因此在启动后登录时，我会在启动时预编译准备好的STMT，以使应用程序进行自检。即使在一个好的rdbms上有100条语句，也只需几秒钟。而且只需一次。这为我节省了很多时间。在一个项目上，DBA不会对nicate（一个不同的团队，在不同的国家）和模式似乎每晚都在无缘无故地改变。每天早上，我们都会得到一个列表，列出它在启动时破坏应用程序的确切位置

如果您需要特殊功能，请将其放在一个命名良好的类中（即命名约定有助于自动匹配测试），该类充当您查询的某种工厂（即，它构建查询）。无论如何，您都必须编写等价的代码，只需将其放在一个可以测试的地方即可。您甚至可以在同一个对象或单独的类中编写一些基本的测试方法

如果可以，也可以尝试使用存储过程。如上所述，它们更难测试。某些数据库也不会在编译时仅在运行时根据架构预先验证存储过程中的sql。通常包括获取架构结构的副本（无数据），然后根据此副本创建所有存储过程（如果进行更改的db团队没有正确验证）。因此可以检查结构。但是作为更改管理的一个要点，存储的过程非常好。更改时所有人都会得到它。特别是当db更改是业务流程更改的结果时。所有语言（java、vb等）都会得到更改

我通常还会设置一个我使用的名为system_setting等的表。在该表中，我们保留了一个版本标识符。这样，客户端库就可以连接并验证它们是否对该版本的架构有效。根据对架构的更改，如果客户端可能损坏您的架构，您不希望允许客户端连接（例如，数据库中没有很多引用规则，但取决于客户端）。这取决于您是否也将有多个客户端版本（这在非web应用程序中确实发生，例如，它们运行的二进制文件错误）。您也可以使用批处理工具等。我也使用的另一种方法是在某种类型的属性文件或system_info表中定义一组模式来操作版本。该表在登录时加载，然后由每个“管理者”使用（我通常使用某种客户端api来完成大多数db工作）验证该操作的版本是否正确。因此，大多数操作都可以成功，但对于过时的方法，也可能失败（引发一些异常），并告诉您原因

管理对架构的更改->是否更新表或向新表添加1-1关系？我看到很多商店总是通过视图来访问数据。这允许表名、列等发生更改。我的想法是将视图视为COM中的接口。例如，为新函数添加新视图个性化/版本。通常情况下，您会看到很多采用表格格式的报表（尤其是最终用户自定义报表）