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

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

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

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


当前回答

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

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

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

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

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

其他回答

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

我们坚持使用变更脚本和主数据定义脚本。这些代码与任何其他源代码一起签入CVS。PL/SQL(我们是Oracle商店)在CVS中也是源代码控制的。变更脚本是可重复的,并且可以传递给团队中的每个人。基本上,仅仅因为它是一个数据库,就没有理由不对它进行编码并使用源代码控制系统来跟踪更改。

是的……我们的数据库是在ERwin中设计的,每个版本的ddl是自动生成的。ERwin文件保存在我们的源代码控制系统中(实际上,我们的工程文档也是如此)。

我对创建脚本进行了版本控制,并在其中使用了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 $');

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

我们在源代码控制下有创建/修改脚本。至于数据库本身,当您有数百个表并且每分钟处理大量数据时,对所有数据库进行版本化将是CPU和HDD的杀手。这就是为什么在我看来,备份仍然是控制数据的最佳方式。