我觉得我的商店有一个漏洞，因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份，所以我们或多或少地得到了保护，但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是，这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题，因为他们的数据库不会经常更改，他们基本上只是尽量做到一丝不苟。
不过，我知道这个故事是怎么发展的。这只是时间问题，迟早会出问题，会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
我们对数据库周围的一切进行版本和源代码控制:
DDL(创建和更改) DML(参考数据、代码等) 数据模型更改(使用ERwin或ER/Studio) 数据库配置更改(权限、安全对象、常规配置更改)
我们使用Change Manager和一些自定义脚本来完成所有这些自动化作业。我们有变更管理器监视这些变更，并在变更完成时通知变更。
其他回答
是的。代码就是代码。我的经验法则是，我需要能够从头构建和部署应用程序，而不需要查看开发或生产机器。
我们正在将所有数据库转移到源代码控制的过程中。我们使用sqlcompare脚本输出数据库(不幸的是，这是一个专业版的特性)，并将结果放到SVN中。
实施的成功将在很大程度上取决于组织的文化和实践。这里的人相信为每个应用程序创建一个数据库。大多数应用程序都使用一组通用的数据库，这也导致了大量的数据库间依赖关系(其中一些是循环的)。由于我们的系统具有数据库间的依赖关系，将数据库模式放到源代码控制中是非常困难的。
祝你好运，你越早尝试，你的问题就会越早解决。
我们维护由ER工具(PowerAMC)生成的DDL(有时是DML)脚本。
我们有一个shell脚本工作台，它重命名以主干分支上的数字开头的脚本。 提交每个脚本并标记bugzilla编号。
这些脚本在需要时与应用程序代码合并到发布分支中。
我们有一个记录脚本及其状态的表。 在部署工具的每次安装中，每个脚本都按顺序执行，并记录在此表中。
我使用SchemaBank来版本控制我所有的数据库模式更改:
从第一天开始，我将我的db模式转储导入其中 我开始用网络浏览器改变我的模式设计(因为它们是基于SaaS /云的) 当我想更新我的db服务器时，我从它生成更改(SQL)脚本并应用到db。在Schemabank中，它们要求我在生成更新脚本之前将工作提交为版本。我喜欢这种练习，这样当我需要的时候，我就可以随时追溯。
我们的团队规则是，在没有存储设计工作之前，永远不要直接接触db服务器。但它发生了，有人可能会被诱惑打破规则，为了方便。我们将再次将模式转储导入到模式银行中，并让它执行diff，如果发现不一致，则对某人进行攻击。虽然我们可以从它生成alter脚本，使我们的db和模式设计同步，但我们讨厌这样做。
顺便说一下，它们还允许我们在版本控制树中创建分支，这样我就可以维护一个用于登台，一个用于生产。还有一个用于编码沙盒。
一个非常整洁的基于web的模式设计工具，带有版本控制和变更管理。
我们使用复制和集群来管理数据库以及备份。我们使用Serena来管理SQL脚本和配置实现。在进行配置更改之前，我们将执行备份，作为更改管理流程的一部分。此备份满足我们的回滚需求。
我认为这完全取决于规模。您是在谈论需要离线备份和灾难恢复的企业应用程序吗?一个运行会计应用程序的小工作组?还是两者之间的任何地方?
