我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
我们维护由ER工具(PowerAMC)生成的DDL(有时是DML)脚本。
我们有一个shell脚本工作台,它重命名以主干分支上的数字开头的脚本。 提交每个脚本并标记bugzilla编号。
这些脚本在需要时与应用程序代码合并到发布分支中。
我们有一个记录脚本及其状态的表。 在部署工具的每次安装中,每个脚本都按顺序执行,并记录在此表中。
其他回答
是的,我认为版本化你的数据库是很重要的。当然不是数据,而是模式。
在Ruby On Rails中,这是由框架通过“迁移”来处理的。任何时候修改db,都需要编写一个脚本来应用更改并将其检入源代码控制。
我的团队非常喜欢这个想法,所以我们使用shell脚本和Ant将该功能添加到基于java的构建中。我们将该过程集成到部署例程中。在其他不支持DB版本开箱即用的框架中编写脚本来完成同样的事情是相当容易的。
我通过保存创建/更新脚本和生成sampledata的脚本来完成。
RedGate软件提供了一些很棒的工具,可以帮助你对数据库进行版本化。确保让开发者为开发工作构建自己的独立本地数据库,而不是依赖于“开发服务器”,因为“开发服务器”有时可能停机,有时也可能不停机。
数据库本身?没有
创建它们的脚本,包括静态数据插入、存储过程等;当然可以。它们是文本文件,它们包含在项目中,像其他东西一样签入和签出。
当然,在理想情况下,您的数据库管理工具可以做到这一点;但你必须遵守纪律。
Kira的主要用例之一是通过显式地将数据库外部的模式指定为代码来进行数据库升级。然后,它可以管理数据库,并将其从任何版本升级到任何版本。