我们在源代码控制下有创建/修改脚本。至于数据库本身，当您有数百个表并且每分钟处理大量数据时，对所有数据库进行版本化将是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

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

我们正在将所有数据库转移到源代码控制的过程中。我们使用sqlcompare脚本输出数据库(不幸的是，这是一个专业版的特性)，并将结果放到SVN中。

实施的成功将在很大程度上取决于组织的文化和实践。这里的人相信为每个应用程序创建一个数据库。大多数应用程序都使用一组通用的数据库，这也导致了大量的数据库间依赖关系(其中一些是循环的)。由于我们的系统具有数据库间的依赖关系，将数据库模式放到源代码控制中是非常困难的。

祝你好运，你越早尝试，你的问题就会越早解决。

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

查看使用源代码控制管理数据库更改的LiquiBase。

我已经使用RedGate SQL Compare Pro与脚本文件夹进行模式同步，然后我将所有更新提交给版本控制。效果很好。