我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
我们有一个每周的sql转储到一个颠覆回购。这是完全自动化的,但这是一项非常繁重的任务。
你会想要限制修改的数量,因为它真的会在一段时间后消耗磁盘空间!
其他回答
数据库本身?没有
创建它们的脚本,包括静态数据插入、存储过程等;当然可以。它们是文本文件,它们包含在项目中,像其他东西一样签入和签出。
当然,在理想情况下,您的数据库管理工具可以做到这一点;但你必须遵守纪律。
“简短版本:将您的生产数据库转储到git存储库中,以实现即时备份解决方案。”
我相信每个DB都应该在源代码控制下,开发人员应该有一种简单的方法从头创建他们的本地数据库。受Visual Studio for Database Professionals的启发,我创建了一个开源工具,脚本MS SQL数据库,并提供了一种简单的方法将它们部署到您的本地DB引擎。试试http://dbsourcetools.codeplex.com/。玩得开心, -内森。
要求开发团队使用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/
作为一种规则,我们将所有的对象代码(存储过程、视图、触发器、函数等)都保存在源代码控制中,因为这些对象都是代码,而且几乎所有其他答案都同意,代码属于某种形式的版本控制系统。
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.
例如,当您将生产数据库恢复到集成环境中时,可以看到一些好处,系统会自动准确地知道哪些脚本没有运行,并将更改新恢复的数据库的表结构,使其与开发相关。