我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
Visual Studio中的新数据库项目提供了源代码控制和更改脚本。
他们有一个很好的工具,可以比较数据库,并可以生成一个脚本,将一个数据库的模式转换为另一个数据库,或者更新一个数据库中的数据以匹配另一个数据库。
db模式被“分解”以创建许多许多小的.sql文件,每个DDL命令一个描述db。
+tom
附加信息2008-11-30
作为一名开发人员,我在过去的一年里一直在使用它,我真的很喜欢它。它可以很容易地比较我的开发工作和生产工作,并生成用于发布的脚本。我不知道它是否缺少dba在“企业级”项目中所需要的特性。
因为模式被“分解”到sql文件中,所以源代码控制可以正常工作。
One gotcha is that you need to have a different mindset when you use a db project. The tool has a "db project" in VS, which is just the sql, plus an automatically generated local database which has the schema and some other admin data -- but none of your application data, plus your local dev db that you use for app data dev work. You rarely are aware of the automatically generated db, but you have to know its there so you can leave it alone :). This special db is clearly recognizable because it has a Guid in its name,
VS DB项目在将其他团队成员所做的DB更改集成到您的本地项目/相关DB方面做得很好。但是您需要采取额外的步骤,将项目模式与本地dev db模式进行比较,并应用mods。这是有道理的,但一开始似乎很尴尬。
DB项目是一个非常强大的工具。它们不仅生成脚本,而且可以立即应用它们。请确保不要用它破坏您的生产数据库。;)
我真的很喜欢VS DB项目,我希望在我所有的DB项目中使用这个工具。
+tom
其他回答
虽然这个问题有很多很好的答案,但大多数答案都不包括市场上的创新变化,特别是商业工具。
下面是一个简短的数据库版本控制工具列表,我列出了每个工具的优缺点(完全披露:我为DBmaestro工作)
红门——已经上市很多年了。它使用集成了基于文件的版本控制的脚本来提供数据库对象的版本控制。
DBVS——使用集成了基于文件的版本控制的脚本来提供数据库对象的版本控制。
DBmaestro——在真实的数据库对象上提供版本控制过程(签出/签入)的强制执行。因此,版本控制存储库是否与应用程序使用的数据库同步是没有问题的。
我鼓励您阅读资深数据库专家Ben Taylor在LinkedIn https://www.linkedin.com/pulse/article/20140907002729-287832-solve-database-change-mangement-with-dbmaestro上发布的关于数据库强制变更管理解决方案的全面、公正的评论
我们在源代码控制下有创建/修改脚本。至于数据库本身,当您有数百个表并且每分钟处理大量数据时,对所有数据库进行版本化将是CPU和HDD的杀手。这就是为什么在我看来,备份仍然是控制数据的最佳方式。
我已经在http://dbdeploy.com/上使用了ThoughtWorks的dbdeploy工具。它鼓励使用迁移脚本。在每个版本中,我们将更改脚本合并到一个文件中,以简化理解,并允许dba“支持”更改。
我所见过的最佳实践是创建一个构建脚本,在登台服务器上废弃并重新构建数据库。每次迭代都有一个用于数据库更改的文件夹,所有更改都用“Drop…创建“”。这样,您可以通过将构建指向您想要版本的文件夹,随时回滚到较早的版本。
我相信这是用NaNt/CruiseControl完成的。
我使用SchemaBank来版本控制我所有的数据库模式更改:
从第一天开始,我将我的db模式转储导入其中 我开始用网络浏览器改变我的模式设计(因为它们是基于SaaS /云的) 当我想更新我的db服务器时,我从它生成更改(SQL)脚本并应用到db。在Schemabank中,它们要求我在生成更新脚本之前将工作提交为版本。我喜欢这种练习,这样当我需要的时候,我就可以随时追溯。
我们的团队规则是,在没有存储设计工作之前,永远不要直接接触db服务器。但它发生了,有人可能会被诱惑打破规则,为了方便。我们将再次将模式转储导入到模式银行中,并让它执行diff,如果发现不一致,则对某人进行攻击。虽然我们可以从它生成alter脚本,使我们的db和模式设计同步,但我们讨厌这样做。
顺便说一下,它们还允许我们在版本控制树中创建分支,这样我就可以维护一个用于登台,一个用于生产。还有一个用于编码沙盒。
一个非常整洁的基于web的模式设计工具,带有版本控制和变更管理。