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

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

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

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

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

A big problem, often overlooked, is that for larger web based systems, it is required to have a transitional period or bucket testing approach to making new releases. This makes it essential to have both rollback and a mechanism for supporting both the old and new schema in the same DB. This requires a scaffolding approach (made populist by the Agile DB folks). In this scenario, lack of process in DB source control can be a total disaster. You need old schema scripts, new schema scripts and a set of intermediate scripts, as well as a tidy up, once the system is fully on the new version (or rolled back).

需要的不是从头开始重新创建模式的脚本，而是一种基于状态的方法，在这种方法中，您只需要脚本将DB从一个版本移动到另一个版本，向前或向后移动到所需的状态。您的DB变成了一系列状态脚本，可以轻松地对其进行源代码控制，并与源代码的其余部分一起标记。

必须阅读将数据库置于版本控制之下。查看K. Scott Allen的系列帖子。

When it comes to version control, the database is often a second or even third-class citizen. From what I've seen, teams that would never think of writing code without version control in a million years-- and rightly so-- can somehow be completely oblivious to the need for version control around the critical databases their applications rely on. I don't know how you can call yourself a software engineer and maintain a straight face when your database isn't under exactly the same rigorous level of source control as the rest of your code. Don't let this happen to you. Get your database under version control.

“简短版本:将您的生产数据库转储到git存储库中，以实现即时备份解决方案。”