database - 对数据库使用源代码管理项目?

  显示原文与译文双语对照的内容

我觉得我的商店有一个漏洞,因为我们没有一个坚实的流程来实现数据库架构更改的版本控制。 我们做了大量的备份,所以我们或多或少都会被覆盖,但这是不正确的做法,依靠你的最后防线。

令人惊讶的是,这似乎是一个共同的线索。 和我交谈过的许多商店忽视这个问题,因为他们的数据库不经常更改,他们基本上只是尽量细致。

但是,我知道那个故事是怎样的。 只是一个时间问题排队只是错了,一些失踪的事情。

是否有任何最佳实践? 哪些策略对你有帮助?

时间:

你绝不应该登录并开始输入"更改表格"命令来更改生产数据库。 我所在的项目在每个客户站点上都有数据库,所以对数据库的每次更改都会在两个位置上创建一个转储文件,该转储文件用于在一个新的客户站点上创建一个新数据库,并在每个更新中检查数据库版本号,并更新你的数据库。 例如最后两个更新:


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

我相信有一个更好的方法来做这个,但这对我来说是有效的。

...