关于数据库模型本身有很多讨论，但是我们也将所需的数据保存在. sql文件中。

例如，为了让你的应用程序更有用，你可能需要在安装时这样做:

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('AUD', 'Australian Dollars');

INSERT INTO Currency (CurrencyCode, CurrencyName) 
VALUES ('USD', 'US Dollars');

我们会有一个名为currency的文件。subversion下的SQL。作为构建过程中的一个手动步骤，我们将比较以前的货币。SQL到最新版本，并编写升级脚本。

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

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

我对创建脚本进行了版本控制，并在其中使用了svn版本标记。然后，每当我得到一个将要使用的版本时，我就在dbpatches/目录中创建一个脚本，命名为要上卷到的版本。该脚本的任务是在不破坏数据的情况下修改当前数据库。例如，Dbpatches /可能有名为201、220和240的文件。如果数据库当前处于201级别，则应用补丁220，然后再应用补丁240。

DROP TABLE IF EXISTS `meta`;
CREATE TABLE `meta` (
  `property` varchar(255),
  `value` varchar(255),
  PRIMARY KEY (`property`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
INSERT INTO `meta` VALUES ('version', '$Rev: 240 $');

在考虑一个好的补丁之前，不要忘记测试你的代码。购者自慎!

数据库本身?没有

创建它们的脚本，包括静态数据插入、存储过程等;当然可以。它们是文本文件，它们包含在项目中，像其他东西一样签入和签出。

当然，在理想情况下，您的数据库管理工具可以做到这一点;但你必须遵守纪律。

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

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

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