我觉得我的商店有一个漏洞,因为我们没有一个可靠的过程来控制数据库模式更改的版本。我们做了很多备份,所以我们或多或少地得到了保护,但以这种方式依赖于最后一道防线是一种糟糕的做法。

令人惊讶的是,这似乎是一个共同的主线。与我交谈过的许多商店都忽略了这个问题,因为他们的数据库不会经常更改,他们基本上只是尽量做到一丝不苟。

不过,我知道这个故事是怎么发展的。这只是时间问题,迟早会出问题,会有东西丢失。

在这方面有什么最佳实践吗?你有哪些行之有效的策略?


当前回答

我非常喜欢Rails ActiveRecord迁移。它将DML抽象为ruby脚本,然后可以在源存储库中轻松地进行版本化。

然而,通过一些工作,您可以做到同样的事情。任何DDL更改(ALTER TABLE等)都可以存储在文本文件中。为文件名保留编号系统(或日期戳),并按顺序应用它们。

Rails在DB中还有一个'version'表,用于跟踪上一次应用的迁移。你可以很容易地做到这一点。

其他回答

我们在源代码控制下有创建/修改脚本。至于数据库本身,当您有数百个表并且每分钟处理大量数据时,对所有数据库进行版本化将是CPU和HDD的杀手。这就是为什么在我看来,备份仍然是控制数据的最佳方式。

是的,我们的源代码控制我们的sql脚本也与subversion。这是一个很好的实践,您可以在需要时使用默认数据重新创建模式。

我非常喜欢Rails ActiveRecord迁移。它将DML抽象为ruby脚本,然后可以在源存储库中轻松地进行版本化。

然而,通过一些工作,您可以做到同样的事情。任何DDL更改(ALTER TABLE等)都可以存储在文本文件中。为文件名保留编号系统(或日期戳),并按顺序应用它们。

Rails在DB中还有一个'version'表,用于跟踪上一次应用的迁移。你可以很容易地做到这一点。

查看使用源代码控制管理数据库更改的LiquiBase。

My team versions our database schema as C# classes with the rest of our code. We have a homegrown C# program (<500 lines of code) that reflects the classes and creates SQL commands to build, drop and update the database. After creating the database we run sqlmetal to generate a linq mapping, which is then compiled in another project that is used to generate test data. The whole things works really well because data access is checked at compile time. We like it because the schema is stored in a .cs file which is easy to track compare in trac/svn.