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

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

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

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


当前回答

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

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

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

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

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

其他回答

我已经开始研究sqlHawk,它的目标是围绕这个问题提供(开源)工具。

它目前处于相当早期的阶段,但已经支持存储和执行存储过程以及运行脚本更新。

如果有任何人有时间看这个工具,我将非常感激。

为公然的自我推销道歉,但我希望这对某人有用!

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

我们正在将所有数据库转移到源代码控制的过程中。我们使用sqlcompare脚本输出数据库(不幸的是,这是一个专业版的特性),并将结果放到SVN中。

实施的成功将在很大程度上取决于组织的文化和实践。这里的人相信为每个应用程序创建一个数据库。大多数应用程序都使用一组通用的数据库,这也导致了大量的数据库间依赖关系(其中一些是循环的)。由于我们的系统具有数据库间的依赖关系,将数据库模式放到源代码控制中是非常困难的。

祝你好运,你越早尝试,你的问题就会越早解决。

我总是检查我的数据库结构转储到源代码控制。全数据库转储,但我通常只是压缩和存储。

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

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

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

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

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