我通过保存创建/更新脚本和生成sampledata的脚本来完成。

在我们的业务中，我们使用数据库更改脚本。运行脚本时，它的名称存储在数据库中，并且不会再次运行，除非删除该行。脚本是基于日期、时间和代码分支命名的，因此可以控制执行。

在脚本在实际环境中运行之前，已经完成了大量的测试，所以一般来说，“oopsies”只发生在开发数据库上。

是的，我们通过保留SQL作为构建的一部分来做到这一点——我们保留DROP。sql,创造。sql,用户。sql,值。SQL和版本控制，所以我们可以恢复到任何带标签的版本。

我们还有ant任务，可以在需要时重新创建db。

此外，SQL还被标记为与之配套的源代码。

是的，我认为版本化你的数据库是很重要的。当然不是数据，而是模式。

在Ruby On Rails中，这是由框架通过“迁移”来处理的。任何时候修改db，都需要编写一个脚本来应用更改并将其检入源代码控制。

我的团队非常喜欢这个想法，所以我们使用shell脚本和Ant将该功能添加到基于java的构建中。我们将该过程集成到部署例程中。在其他不支持DB版本开箱即用的框架中编写脚本来完成同样的事情是相当容易的。

我们维护由ER工具(PowerAMC)生成的DDL(有时是DML)脚本。

我们有一个shell脚本工作台，它重命名以主干分支上的数字开头的脚本。 提交每个脚本并标记bugzilla编号。

这些脚本在需要时与应用程序代码合并到发布分支中。

我们有一个记录脚本及其状态的表。 在部署工具的每次安装中，每个脚本都按顺序执行，并记录在此表中。

I've heard people say you absolutely have to keep your schemas in the database. I'm not sure I agree. This really depends on the system you're working with. If your system is relatively small and the data is not terribly important. And the the speed at which you need to bring another development environment online is crucial.. then yes.. you can benefit from it. However when your schema is useless without the data and the database is extremely large, it becomes virtually impossible to "source control" your database. Sure, you can still keep your DDL code in source control but that's essentially useless. You can't get the data needed without backup/restore.

在大型数据库开发工作中，我发现备份和恢复是首选的回滚选项。当然，你可以在源代码控制中保留过程、视图、函数等，但要保留表。SQL不是必需的。此外，如果您的部署过程是无懈可击的，那么您很可能永远不需要“回滚”您的生产环境。