我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
我通常为我所做的每一个更改构建一个SQL脚本,另一个用于恢复这些更改,并将这些脚本置于版本控制之下。
这样我们就可以根据需要创建一个新的最新数据库,并且可以轻松地在不同版本之间切换。每次我们发布版本时,我们都会把脚本放在一起(需要一些手工工作,但实际上很少困难),所以我们也有一组可以在版本之间转换的脚本。
是的,在你说之前,这与Rails和其他东西非常相似,但它似乎工作得很好,所以我毫不犹豫地承认我无耻地提出了这个想法:)
其他回答
我们在源代码控制下有创建/修改脚本。至于数据库本身,当您有数百个表并且每分钟处理大量数据时,对所有数据库进行版本化将是CPU和HDD的杀手。这就是为什么在我看来,备份仍然是控制数据的最佳方式。
“简短版本:将您的生产数据库转储到git存储库中,以实现即时备份解决方案。”
作为一种规则,我们将所有的对象代码(存储过程、视图、触发器、函数等)都保存在源代码控制中,因为这些对象都是代码,而且几乎所有其他答案都同意,代码属于某种形式的版本控制系统。
As for CREATE, DROP, ALTER statements, etc. (DDL), we developed and use BuildMaster to manage the deployment of these scripts such that they can be run once and only once against a target database (whether they fail or not). The general idea is that developers will upload change scripts into the system and when it comes time for deployment, only the change scripts that haven't been run against the target environment's database will be run (this is managed very similarly to Autocracy's answer). The reason for this separation of script types lies in that once you manipulate a table's structure, add an index, etc., you effectively cannot undo that without writing a brand new script, or restoring the database - as opposed to the object code where you can simply drop a view or stored procedure then recreate it.
例如,当您将生产数据库恢复到集成环境中时,可以看到一些好处,系统会自动准确地知道哪些脚本没有运行,并将更改新恢复的数据库的表结构,使其与开发相关。
这对我来说也一直是一个很大的烦恼——似乎对开发数据库进行快速更改,保存它(忘记保存更改脚本)太容易了,然后你就卡在那里了。您可以撤消刚才所做的并重新做它以创建更改脚本,当然,如果您愿意的话,也可以从头开始编写它,尽管这将花费大量的时间来编写脚本。
A tool that I have used in the past that has helped with this some is SQL Delta. It will show you the differences between two databases (SQL server/Oracle I believe) and generate all the change scripts necessary to migrate A->B. Another nice thing it does is show all the differences between database content between the production (or test) DB and your development DB. Since more and more apps store configuration and state that is crucial to their execution in database tables, it can be a real pain to have change scripts that remove, add, and alter the proper rows. SQL Delta shows the rows in the database just like they would look in a Diff tool - changed, added, deleted.
一个很好的工具。以下是链接: http://www.sqldelta.com/
是的,我们通过保留SQL作为构建的一部分来做到这一点——我们保留DROP。sql,创造。sql,用户。sql,值。SQL和版本控制,所以我们可以恢复到任何带标签的版本。
我们还有ant任务,可以在需要时重新创建db。
此外,SQL还被标记为与之配套的源代码。