我非常喜欢Rails ActiveRecord迁移。它将DML抽象为ruby脚本，然后可以在源存储库中轻松地进行版本化。

然而，通过一些工作，您可以做到同样的事情。任何DDL更改(ALTER TABLE等)都可以存储在文本文件中。为文件名保留编号系统(或日期戳)，并按顺序应用它们。

Rails在DB中还有一个'version'表，用于跟踪上一次应用的迁移。你可以很容易地做到这一点。

我非常喜欢Rails ActiveRecord迁移。它将DML抽象为ruby脚本，然后可以在源存储库中轻松地进行版本化。

然而，通过一些工作，您可以做到同样的事情。任何DDL更改(ALTER TABLE等)都可以存储在文本文件中。为文件名保留编号系统(或日期戳)，并按顺序应用它们。

Rails在DB中还有一个'version'表，用于跟踪上一次应用的迁移。你可以很容易地做到这一点。

我通过编写脚本输出所有对象(表定义、索引、存储过程等)来源控制数据库模式。但是，至于数据本身，只需依赖定期备份。这确保了所有的结构更改都被正确的修订历史记录捕获，但不会在每次数据更改时给数据库带来负担。

我们使用复制和集群来管理数据库以及备份。我们使用Serena来管理SQL脚本和配置实现。在进行配置更改之前，我们将执行备份，作为更改管理流程的一部分。此备份满足我们的回滚需求。

我认为这完全取决于规模。您是在谈论需要离线备份和灾难恢复的企业应用程序吗?一个运行会计应用程序的小工作组?还是两者之间的任何地方?

我通常为我所做的每一个更改构建一个SQL脚本，另一个用于恢复这些更改，并将这些脚本置于版本控制之下。

这样我们就可以根据需要创建一个新的最新数据库，并且可以轻松地在不同版本之间切换。每次我们发布版本时，我们都会把脚本放在一起(需要一些手工工作，但实际上很少困难)，所以我们也有一组可以在版本之间转换的脚本。

是的，在你说之前，这与Rails和其他东西非常相似，但它似乎工作得很好，所以我毫不犹豫地承认我无耻地提出了这个想法:)

Sadly, I've seen more than one team developing PL/SQL programs (stored procedures in Oracle) - sometimes ten thousands LOC - just by editing the code in TOAD (a database tool), without even saving the source to files (except for deployment). Even if the database is backuped regulary (wouldn't take that for granted, though), the only way to retrieve an old version of a stored procedure is to restore the whole database, which is many GB large. And of course sometimes concurrent changes in one file lead to loss of work, when more than one developer works on the same project.