我觉得我的商店有一个漏洞，因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份，所以我们或多或少地得到了保护，但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是，这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题，因为他们的数据库不会经常更改，他们基本上只是尽量做到一丝不苟。
不过，我知道这个故事是怎么发展的。这只是时间问题，迟早会出问题，会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
是的，我认为版本化你的数据库是很重要的。当然不是数据，而是模式。
在Ruby On Rails中，这是由框架通过“迁移”来处理的。任何时候修改db，都需要编写一个脚本来应用更改并将其检入源代码控制。
我的团队非常喜欢这个想法，所以我们使用shell脚本和Ant将该功能添加到基于java的构建中。我们将该过程集成到部署例程中。在其他不支持DB版本开箱即用的框架中编写脚本来完成同样的事情是相当容易的。
其他回答
RedGate很棒，当数据库发生变化时，我们会生成新的快照(一个小的二进制文件)，并将该文件作为资源保存在项目中。每当我们需要更新数据库时，我们使用RedGate的工具包来更新数据库，并且能够从空数据库创建新的数据库。
RedGate也制作数据快照，虽然我个人没有使用过，但它们同样强大。
我已经使用RedGate SQL Compare Pro与脚本文件夹进行模式同步，然后我将所有更新提交给版本控制。效果很好。
我们对所有dabase创建的对象进行源代码控制。为了让开发人员保持诚实(因为你可以在没有源代码控制的情况下创建对象)，我们的dba定期寻找不在源代码控制中的任何东西，如果他们找到了什么，他们就会丢弃它，而不询问它是否ok。
任何数据库接口代码都应该进入版本控制(存储过程、函数等)。
对于结构和数据，这是一个判断。我个人对我的数据库保持一个干净的结构模板，但由于它们的大小，不将它们存储在版本控制中。但是将它存储在版本控制中是非常有益的，即使对于只有历史记录也是如此。
我使用SchemaBank来版本控制我所有的数据库模式更改:
从第一天开始，我将我的db模式转储导入其中 我开始用网络浏览器改变我的模式设计(因为它们是基于SaaS /云的) 当我想更新我的db服务器时，我从它生成更改(SQL)脚本并应用到db。在Schemabank中，它们要求我在生成更新脚本之前将工作提交为版本。我喜欢这种练习，这样当我需要的时候，我就可以随时追溯。
我们的团队规则是，在没有存储设计工作之前，永远不要直接接触db服务器。但它发生了，有人可能会被诱惑打破规则，为了方便。我们将再次将模式转储导入到模式银行中，并让它执行diff，如果发现不一致，则对某人进行攻击。虽然我们可以从它生成alter脚本，使我们的db和模式设计同步，但我们讨厌这样做。
顺便说一下，它们还允许我们在版本控制树中创建分支，这样我就可以维护一个用于登台，一个用于生产。还有一个用于编码沙盒。
一个非常整洁的基于web的模式设计工具，带有版本控制和变更管理。
