我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
如果你的数据库是SQL Server,我们可能有你正在寻找的解决方案。SQL源代码控制1.0现在已经发布了。
http://www.red-gate.com/products/SQL_Source_Control/index.htm
它集成到SSMS中,并提供数据库对象和VCS之间的粘合剂。“脚本输出”是透明的(它在底层使用SQL比较引擎),这应该使它使用起来如此简单,以至于开发人员不会被阻止采用该过程。
一个可供选择的Visual Studio解决方案是ReadyRoll,它被实现为SSDT数据库项目的子类型。这采用了一种迁移驱动的方法,更适合DevOps团队的自动化需求。
其他回答
数据库本身?没有
创建它们的脚本,包括静态数据插入、存储过程等;当然可以。它们是文本文件,它们包含在项目中,像其他东西一样签入和签出。
当然,在理想情况下,您的数据库管理工具可以做到这一点;但你必须遵守纪律。
查看使用源代码控制管理数据库更改的LiquiBase。
我们有一个每周的sql转储到一个颠覆回购。这是完全自动化的,但这是一项非常繁重的任务。
你会想要限制修改的数量,因为它真的会在一段时间后消耗磁盘空间!
仅供参考,几天前Dana也提出了这个问题…源代码控制中的存储过程/DB模式
我们在源代码控制下有创建/修改脚本。至于数据库本身,当您有数百个表并且每分钟处理大量数据时,对所有数据库进行版本化将是CPU和HDD的杀手。这就是为什么在我看来,备份仍然是控制数据的最佳方式。