我觉得我的商店有一个漏洞，因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份，所以我们或多或少地得到了保护，但以这种方式依赖于最后一道防线是一种糟糕的做法。
令人惊讶的是，这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题，因为他们的数据库不会经常更改，他们基本上只是尽量做到一丝不苟。
不过，我知道这个故事是怎么发展的。这只是时间问题，迟早会出问题，会有东西丢失。
在这方面有什么最佳实践吗?你有哪些行之有效的策略?
当前回答
我非常喜欢Rails ActiveRecord迁移。它将DML抽象为ruby脚本，然后可以在源存储库中轻松地进行版本化。
然而，通过一些工作，您可以做到同样的事情。任何DDL更改(ALTER TABLE等)都可以存储在文本文件中。为文件名保留编号系统(或日期戳)，并按顺序应用它们。
Rails在DB中还有一个'version'表，用于跟踪上一次应用的迁移。你可以很容易地做到这一点。
其他回答
是的……我们的数据库是在ERwin中设计的，每个版本的ddl是自动生成的。ERwin文件保存在我们的源代码控制系统中(实际上，我们的工程文档也是如此)。
在我们的业务中，我们使用数据库更改脚本。运行脚本时，它的名称存储在数据库中，并且不会再次运行，除非删除该行。脚本是基于日期、时间和代码分支命名的，因此可以控制执行。
在脚本在实际环境中运行之前，已经完成了大量的测试，所以一般来说，“oopsies”只发生在开发数据库上。
Kira的主要用例之一是通过显式地将数据库外部的模式指定为代码来进行数据库升级。然后，它可以管理数据库，并将其从任何版本升级到任何版本。
我非常喜欢Rails ActiveRecord迁移。它将DML抽象为ruby脚本，然后可以在源存储库中轻松地进行版本化。
然而，通过一些工作，您可以做到同样的事情。任何DDL更改(ALTER TABLE等)都可以存储在文本文件中。为文件名保留编号系统(或日期戳)，并按顺序应用它们。
Rails在DB中还有一个'version'表，用于跟踪上一次应用的迁移。你可以很容易地做到这一点。
哇，这么多答案。对于可靠的数据库版本控制，您需要对更改数据库的代码进行版本控制。一些CMS提供配置管理工具，比如Drupal 8中的配置管理工具。以下是一个实用步骤的概述，可以安排您的工作流并确保数据库配置是版本化的，即使是在团队环境中:
