我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
对于oracle,我使用自己编写的java程序oracle-ddl2svn自动跟踪oracle DDL方案在SVN中的变化
其他回答
RedGate很棒,当数据库发生变化时,我们会生成新的快照(一个小的二进制文件),并将该文件作为资源保存在项目中。每当我们需要更新数据库时,我们使用RedGate的工具包来更新数据库,并且能够从空数据库创建新的数据库。
RedGate也制作数据快照,虽然我个人没有使用过,但它们同样强大。
是的,我认为版本化你的数据库是很重要的。当然不是数据,而是模式。
在Ruby On Rails中,这是由框架通过“迁移”来处理的。任何时候修改db,都需要编写一个脚本来应用更改并将其检入源代码控制。
我的团队非常喜欢这个想法,所以我们使用shell脚本和Ant将该功能添加到基于java的构建中。我们将该过程集成到部署例程中。在其他不支持DB版本开箱即用的框架中编写脚本来完成同样的事情是相当容易的。
我已经开始研究sqlHawk,它的目标是围绕这个问题提供(开源)工具。
它目前处于相当早期的阶段,但已经支持存储和执行存储过程以及运行脚本更新。
如果有任何人有时间看这个工具,我将非常感激。
为公然的自我推销道歉,但我希望这对某人有用!
任何数据库接口代码都应该进入版本控制(存储过程、函数等)。
对于结构和数据,这是一个判断。我个人对我的数据库保持一个干净的结构模板,但由于它们的大小,不将它们存储在版本控制中。但是将它存储在版本控制中是非常有益的,即使对于只有历史记录也是如此。
我使用SQL CREATE脚本从MySQL workbench导出,然后使用他们的“导出SQL ALTER”功能,我最终得到了一系列创建脚本(当然编号)和ALTER脚本,可以应用它们之间的更改。
3.- Export SQL ALTER script Normally you would have to write the ALTER TABLE statements by hand now, reflecting your changes you made to the model. But you can be smart and let Workbench do the hard work for you. Simply select File -> Export -> Forward Engineer SQL ALTER Script… from the main menu. This will prompt you to specify the SQL CREATE file the current model should be compared to. Select the SQL CREATE script from step 1. The tool will then generate the ALTER TABLE script for you and you can execute this script against your database to bring it up to date. You can do this using the MySQL Query Browser or the mysql client.Voila! Your model and database have now been synchronized!
来源:MySQL Workbench Community Edition: Schema同步指南
当然,所有这些脚本都在版本控制下。