我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
是的。代码就是代码。我的经验法则是,我需要能够从头构建和部署应用程序,而不需要查看开发或生产机器。
其他回答
我们坚持使用变更脚本和主数据定义脚本。这些代码与任何其他源代码一起签入CVS。PL/SQL(我们是Oracle商店)在CVS中也是源代码控制的。变更脚本是可重复的,并且可以传递给团队中的每个人。基本上,仅仅因为它是一个数据库,就没有理由不对它进行编码并使用源代码控制系统来跟踪更改。
必须阅读将数据库置于版本控制之下。查看K. Scott Allen的系列帖子。
When it comes to version control, the database is often a second or even third-class citizen. From what I've seen, teams that would never think of writing code without version control in a million years-- and rightly so-- can somehow be completely oblivious to the need for version control around the critical databases their applications rely on. I don't know how you can call yourself a software engineer and maintain a straight face when your database isn't under exactly the same rigorous level of source control as the rest of your code. Don't let this happen to you. Get your database under version control.
要求开发团队使用SQL数据库源代码控制管理系统并不是防止问题发生的灵丹妙药。就其本身而言,数据库源代码控制引入了额外的开销,因为开发人员需要将他们对对象所做的更改保存在单独的SQL脚本中,打开源代码控制系统客户端,使用客户端签入SQL脚本文件,然后将更改应用到活动数据库。
我可以建议使用SSMS插件ApexSQL源代码控制。它允许开发人员通过向导直接从SSMS轻松地将数据库对象映射到源代码控制系统。该插件支持TFS、Git、Subversion和其他SC系统。它还包括对源控制静态数据的支持。
下载并安装ApexSQL源代码控制后,只需右键单击要进行版本控制的数据库,然后导航到SSMS中的ApexSQL源代码控制子菜单。单击Link database to source control选项,选择源代码控制系统和开发模型。之后,您需要为所选择的源代码控制系统提供登录信息和存储库字符串。
你可以阅读这篇文章了解更多信息:http://solutioncenter.apexsql.com/sql-source-control-reduce-database-development-time/
我们有一个每周的sql转储到一个颠覆回购。这是完全自动化的,但这是一项非常繁重的任务。
你会想要限制修改的数量,因为它真的会在一段时间后消耗磁盘空间!
作为一种规则,我们将所有的对象代码(存储过程、视图、触发器、函数等)都保存在源代码控制中,因为这些对象都是代码,而且几乎所有其他答案都同意,代码属于某种形式的版本控制系统。
As for CREATE, DROP, ALTER statements, etc. (DDL), we developed and use BuildMaster to manage the deployment of these scripts such that they can be run once and only once against a target database (whether they fail or not). The general idea is that developers will upload change scripts into the system and when it comes time for deployment, only the change scripts that haven't been run against the target environment's database will be run (this is managed very similarly to Autocracy's answer). The reason for this separation of script types lies in that once you manipulate a table's structure, add an index, etc., you effectively cannot undo that without writing a brand new script, or restoring the database - as opposed to the object code where you can simply drop a view or stored procedure then recreate it.
例如,当您将生产数据库恢复到集成环境中时,可以看到一些好处,系统会自动准确地知道哪些脚本没有运行,并将更改新恢复的数据库的表结构,使其与开发相关。