我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
数据库本身?没有
创建它们的脚本,包括静态数据插入、存储过程等;当然可以。它们是文本文件,它们包含在项目中,像其他东西一样签入和签出。
当然,在理想情况下,您的数据库管理工具可以做到这一点;但你必须遵守纪律。
其他回答
我们对数据库周围的一切进行版本和源代码控制:
DDL(创建和更改) DML(参考数据、代码等) 数据模型更改(使用ERwin或ER/Studio) 数据库配置更改(权限、安全对象、常规配置更改)
我们使用Change Manager和一些自定义脚本来完成所有这些自动化作业。我们有变更管理器监视这些变更,并在变更完成时通知变更。
是的,我们通过保留SQL作为构建的一部分来做到这一点——我们保留DROP。sql,创造。sql,用户。sql,值。SQL和版本控制,所以我们可以恢复到任何带标签的版本。
我们还有ant任务,可以在需要时重新创建db。
此外,SQL还被标记为与之配套的源代码。
我相信每个DB都应该在源代码控制下,开发人员应该有一种简单的方法从头创建他们的本地数据库。受Visual Studio for Database Professionals的启发,我创建了一个开源工具,脚本MS SQL数据库,并提供了一种简单的方法将它们部署到您的本地DB引擎。试试http://dbsourcetools.codeplex.com/。玩得开心, -内森。
我总是检查我的数据库结构转储到源代码控制。全数据库转储,但我通常只是压缩和存储。
虽然这个问题有很多很好的答案,但大多数答案都不包括市场上的创新变化,特别是商业工具。
下面是一个简短的数据库版本控制工具列表,我列出了每个工具的优缺点(完全披露:我为DBmaestro工作)
红门——已经上市很多年了。它使用集成了基于文件的版本控制的脚本来提供数据库对象的版本控制。
DBVS——使用集成了基于文件的版本控制的脚本来提供数据库对象的版本控制。
DBmaestro——在真实的数据库对象上提供版本控制过程(签出/签入)的强制执行。因此,版本控制存储库是否与应用程序使用的数据库同步是没有问题的。
我鼓励您阅读资深数据库专家Ben Taylor在LinkedIn https://www.linkedin.com/pulse/article/20140907002729-287832-solve-database-change-mangement-with-dbmaestro上发布的关于数据库强制变更管理解决方案的全面、公正的评论