我使用SchemaBank来版本控制我所有的数据库模式更改:

从第一天开始，我将我的db模式转储导入其中 我开始用网络浏览器改变我的模式设计(因为它们是基于SaaS /云的) 当我想更新我的db服务器时，我从它生成更改(SQL)脚本并应用到db。在Schemabank中，它们要求我在生成更新脚本之前将工作提交为版本。我喜欢这种练习，这样当我需要的时候，我就可以随时追溯。

我们的团队规则是，在没有存储设计工作之前，永远不要直接接触db服务器。但它发生了，有人可能会被诱惑打破规则，为了方便。我们将再次将模式转储导入到模式银行中，并让它执行diff，如果发现不一致，则对某人进行攻击。虽然我们可以从它生成alter脚本，使我们的db和模式设计同步，但我们讨厌这样做。

顺便说一下，它们还允许我们在版本控制树中创建分支，这样我就可以维护一个用于登台，一个用于生产。还有一个用于编码沙盒。

一个非常整洁的基于web的模式设计工具，带有版本控制和变更管理。

这对我来说也一直是一个很大的烦恼——似乎对开发数据库进行快速更改，保存它(忘记保存更改脚本)太容易了，然后你就卡在那里了。您可以撤消刚才所做的并重新做它以创建更改脚本，当然，如果您愿意的话，也可以从头开始编写它，尽管这将花费大量的时间来编写脚本。

A tool that I have used in the past that has helped with this some is SQL Delta. It will show you the differences between two databases (SQL server/Oracle I believe) and generate all the change scripts necessary to migrate A->B. Another nice thing it does is show all the differences between database content between the production (or test) DB and your development DB. Since more and more apps store configuration and state that is crucial to their execution in database tables, it can be a real pain to have change scripts that remove, add, and alter the proper rows. SQL Delta shows the rows in the database just like they would look in a Diff tool - changed, added, deleted.

一个很好的工具。以下是链接: http://www.sqldelta.com/

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

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

Kira的主要用例之一是通过显式地将数据库外部的模式指定为代码来进行数据库升级。然后，它可以管理数据库，并将其从任何版本升级到任何版本。

我们在源代码控制下有创建/修改脚本。至于数据库本身，当您有数百个表并且每分钟处理大量数据时，对所有数据库进行版本化将是CPU和HDD的杀手。这就是为什么在我看来，备份仍然是控制数据的最佳方式。

You should never just log in and start entering "ALTER TABLE" commands to change a production database. The project I'm on has database on every customer site, and so every change to the database is made in two places, a dump file that is used to create a new database on a new customer site, and an update file that is run on every update which checks your current database version number against the highest number in the file, and updates your database in place. So for instance, the last couple of updates:

if [ $VERSION \< '8.0.108' ] ; then
  psql -U cosuser $dbName << EOF8.0.108
    BEGIN TRANSACTION;
    --
    -- Remove foreign key that shouldn't have been there.
    -- PCR:35665
    --
    ALTER TABLE     migratorjobitems
    DROP CONSTRAINT migratorjobitems_destcmaid_fkey;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.108'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.108
fi

if [ $VERSION \< '8.0.109' ] ; then
  psql -U cosuser $dbName << EOF8.0.109
    BEGIN TRANSACTION;
    --
    -- I missed a couple of cases when I changed the legacy playlist
    -- from reporting showplaylistidnum to playlistidnum
    --
    ALTER TABLE     featureidrequestkdcs
    DROP CONSTRAINT featureidrequestkdcs_cosfeatureid_fkey;
    ALTER TABLE     featureidrequestkdcs
    ADD CONSTRAINT  featureidrequestkdcs_cosfeatureid_fkey
    FOREIGN KEY     (cosfeatureid)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    --
    ALTER TABLE     ticket_system_ids
    DROP CONSTRAINT ticket_system_ids_showplaylistidnum_fkey;
    ALTER TABLE     ticket_system_ids
    RENAME          showplaylistidnum
    TO              playlistidnum;
    ALTER TABLE     ticket_system_ids
    ADD CONSTRAINT  ticket_system_ids_playlistidnum_fkey
    FOREIGN KEY     (playlistidnum)
    REFERENCES      playlist(playlistidnum)
    ON DELETE       CASCADE;
    -- 
    -- Increment the version
    UPDATE          sys_info
    SET             value = '8.0.109'
    WHERE           key = 'DB VERSION';
    END TRANSACTION;
EOF8.0.109
fi

我相信有更好的方法来做到这一点，但到目前为止，它对我来说是有效的。