我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。
不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
我使用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同步指南
当然,所有这些脚本都在版本控制下。
其他回答
I agree with many of the posting concerning ruby's ActiveRecord migrations - they are an elegant way to manage the database in small incremental files that everyone can share. With that said, I've recently implemented a project using VisualStudio's Database Project, and it's kinda made me a believer. Short story - you create a database project, import all (if any) existing database objects into it (tables/views/triggers/keys/users/etc). That import results in a "Create" script per object. To manage the database you alter the create script and then on deploy VS compares the target database to the state of the database residing in your project and apply the proper alter statements.
这真的有点神奇,我必须承认,这是VS团队做的更好的事情之一。到目前为止,我真的很感动。
当然,您可以在自己选择的版本控制系统中管理整个数据库项目。
RedGate很棒,当数据库发生变化时,我们会生成新的快照(一个小的二进制文件),并将该文件作为资源保存在项目中。每当我们需要更新数据库时,我们使用RedGate的工具包来更新数据库,并且能够从空数据库创建新的数据库。
RedGate也制作数据快照,虽然我个人没有使用过,但它们同样强大。
我使用SchemaBank来版本控制我所有的数据库模式更改:
从第一天开始,我将我的db模式转储导入其中 我开始用网络浏览器改变我的模式设计(因为它们是基于SaaS /云的) 当我想更新我的db服务器时,我从它生成更改(SQL)脚本并应用到db。在Schemabank中,它们要求我在生成更新脚本之前将工作提交为版本。我喜欢这种练习,这样当我需要的时候,我就可以随时追溯。
我们的团队规则是,在没有存储设计工作之前,永远不要直接接触db服务器。但它发生了,有人可能会被诱惑打破规则,为了方便。我们将再次将模式转储导入到模式银行中,并让它执行diff,如果发现不一致,则对某人进行攻击。虽然我们可以从它生成alter脚本,使我们的db和模式设计同步,但我们讨厌这样做。
顺便说一下,它们还允许我们在版本控制树中创建分支,这样我就可以维护一个用于登台,一个用于生产。还有一个用于编码沙盒。
一个非常整洁的基于web的模式设计工具,带有版本控制和变更管理。
是的,总是这样。您应该能够在需要时使用一组有用的示例数据重新创建生产数据库结构。如果你不这样做,随着时间的推移,保持运行的小改变会被遗忘,然后有一天你会被咬,严重的。这是一种保险,你可能认为你不需要,但当你这样做的那一天,它的价格是它的10倍!
RedGate软件提供了一些很棒的工具,可以帮助你对数据库进行版本化。确保让开发者为开发工作构建自己的独立本地数据库,而不是依赖于“开发服务器”,因为“开发服务器”有时可能停机,有时也可能不停机。