我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
是的……我们的数据库是在ERwin中设计的,每个版本的ddl是自动生成的。ERwin文件保存在我们的源代码控制系统中(实际上,我们的工程文档也是如此)。
其他回答
“简短版本:将您的生产数据库转储到git存储库中,以实现即时备份解决方案。”
我们维护由ER工具(PowerAMC)生成的DDL(有时是DML)脚本。
我们有一个shell脚本工作台,它重命名以主干分支上的数字开头的脚本。 提交每个脚本并标记bugzilla编号。
这些脚本在需要时与应用程序代码合并到发布分支中。
我们有一个记录脚本及其状态的表。 在部署工具的每次安装中,每个脚本都按顺序执行,并记录在此表中。
是的,我们的源代码控制我们的sql脚本也与subversion。这是一个很好的实践,您可以在需要时使用默认数据重新创建模式。
我使用SchemaBank来版本控制我所有的数据库模式更改:
从第一天开始,我将我的db模式转储导入其中 我开始用网络浏览器改变我的模式设计(因为它们是基于SaaS /云的) 当我想更新我的db服务器时,我从它生成更改(SQL)脚本并应用到db。在Schemabank中,它们要求我在生成更新脚本之前将工作提交为版本。我喜欢这种练习,这样当我需要的时候,我就可以随时追溯。
我们的团队规则是,在没有存储设计工作之前,永远不要直接接触db服务器。但它发生了,有人可能会被诱惑打破规则,为了方便。我们将再次将模式转储导入到模式银行中,并让它执行diff,如果发现不一致,则对某人进行攻击。虽然我们可以从它生成alter脚本,使我们的db和模式设计同步,但我们讨厌这样做。
顺便说一下,它们还允许我们在版本控制树中创建分支,这样我就可以维护一个用于登台,一个用于生产。还有一个用于编码沙盒。
一个非常整洁的基于web的模式设计工具,带有版本控制和变更管理。
RedGate很棒,当数据库发生变化时,我们会生成新的快照(一个小的二进制文件),并将该文件作为资源保存在项目中。每当我们需要更新数据库时,我们使用RedGate的工具包来更新数据库,并且能够从空数据库创建新的数据库。
RedGate也制作数据快照,虽然我个人没有使用过,但它们同样强大。