我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。

令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。

不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。

在这方面有什么最佳实践吗?你有哪些行之有效的策略?


当前回答

是的。代码就是代码。我的经验法则是,我需要能够从头构建和部署应用程序,而不需要查看开发或生产机器。

其他回答

我对创建脚本进行了版本控制,并在其中使用了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文件中。

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

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

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

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

我们对数据库周围的一切进行版本和源代码控制:

DDL(创建和更改) DML(参考数据、代码等) 数据模型更改(使用ERwin或ER/Studio) 数据库配置更改(权限、安全对象、常规配置更改)

我们使用Change Manager和一些自定义脚本来完成所有这些自动化作业。我们有变更管理器监视这些变更,并在变更完成时通知变更。

是的。代码就是代码。我的经验法则是,我需要能够从头构建和部署应用程序,而不需要查看开发或生产机器。

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